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内 容 提 要 


结构 化 查询 语言 (Structured Query Language，SQL) 是 一 种 功能 强大 的 数据 库 语 言 。 它 基于 关系 
代数 运算 ， 功 能 丰富 、 语 言 简洁 、 使 用 方便 灵活 ， 已 成 为 关系 数据 库 的 标准 语言 。 

本 书 则 在 引导 读者 掌握 SQL 优化 技能 ， 以 更 好 地 提升 数据 库 性 能 。 本 书 共 分 10 章 ， 从 SQL 基础 
知识 、 统 计 信 息 、 执 行 计 划 、 访 问 路 径 、 表 连接 方式 、 成 本 计算 、 查 询 变 换 、 调 优 技巧 、 经 典 案例 、 
全 自动 SQL 审核 等 角度 介绍 了 有 关 SQL 优化 的 方方面面 。 

本 书 基于 Oracle 进行 编写 ， 内 容 讲解 由 浅 入 深 , 适合 各 个 层次 的 读者 学 习 。 本 书面 向 一 线 工 程 师 、 
运 维 工程 师 、 数 据 库 管理 员 以 及 系统 设计 与 开发 人 员 ， 无 论 是 初学 者 还 是 有 一 定 基 础 的 读者 ， 都 将 从 
中 获 益 。 
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近年 来 ， 随 着 系统 的 数据 量 逐 年 增加 ， 并 发 量 也 成 倍增 长 ，SQL 人 性 能 越 来 越 成 为 IT 系统 
设计 和 开发 时 首要 考虑 的 问题 之 一 。SQL 性 能 问题 已 经 逐步 发 展 成 为 数据 库 性 能 的 首要 问题 ， 
80% 的 数据 库 性 能 问题 都 是 因 SQL 而 导致 。 面 对 日 益 增多 的 SQL 性 能 问题 ， 如 何 下 手 以 及 如 
何 提前 审核 已 经 成 为 越 来 越 多 的 YT. 从 业者 必须 要 考虑 的 问题 。 

现在 将 8 年 专职 SQL 优化 的 经 验 和 心得 与 大 家 一 起 分 享 , 以 揭 开 SQL 优化 的 神秘 面纱 ， 
让 一 线 工 程 师 在 实际 开发 中 不 再 首 食 难 安 、 谈 虎 色 变 ， 最 终 能 够 对 SQL 优化 技能 驾轻就熟 。 

编写 本 书 也 是 对 多 年 学 习 积累 的 一 个 总 结 ， 诸 策 自己 再 接 再 厉 。 如 果 能 够 给 各 位 读者 在 
SQL 优化 上 提供 一 点 帮助 ， 也 不 枉 个 中 注音 。 

2014 年 ， 作 者 罗 炳 森 与 有 教 无 类 (网 名 ) 联合 编写 了 《Oracle 查询 优化 改写 技巧 与 案例 》 
一 书 ， 该 书 主要 侧重 于 SQL 优化 改写 技巧 。 到 目前 为 止 ， 该 书 仍然 是 市 面 上 唯一 一 本 专门 讲 
fit SQL 改写 技巧 的 图 书 。 

因为 《Oracle 查询 优化 改写 技巧 与 案例 》 只 专注 于 SQL 改写 技巧 ， 并 没有 涉及 SQL 优化 
的 具体 思想 、 方法 和 步 又， 本 书 可 以 看 作 是 对 《Oracle 查询 优化 改写 技巧 与 案例 》 一 书 的 进 一 
步 补充 。 

本 书 共 10 章 ， 各 章 的 主要 内 容 如 下 。 

第 1 章 详细 介绍 了 SQL 优化 的 基础 知识 以 及 初学 者 切实 需要 掌握 的 基本 内 容 ， 本 章 可 以 
帮助 初学 者 快速 入 门 。 

第 2 章 详细 讲解 统计 信息 定义 、 统 计 信 息 的 重要 性 、 统 计 信 息 相 关 参 数 设置 方案 以 及 统计 
Сеше уч 

第 3 章 详细 讲解 执行 计划 、 各 种 执行 计划 的 使 用 场景 以 及 执行 计划 的 阅读 方法 , 通过 定制 
执行 计划 ， 读 者 可 以 快速 找 出 SQL 性 能 瓶颈 。 

第 4 章 详细 讲解 常见 的 访问 路 径 , 这 是 阅读 执行 计划 中 比较 重要 的 环节 , 需要 掌握 各 种 党 
见 的 访问 路 径 。 

第 5 章 详细 讲解 表 的 各 种 连接 方式 、 各 种 表 连 接 方式 的 等 价 改写 以 及 相互 转换 ,这 也 是 本 
书 的 核心 章节 。 

第 6 章 介绍 单 表 访 问 以 及 索引 扫描 的 成 本 计算 方法 ， 并 由 此 引出 SQL 优化 的 核心 思想 。 

第 7 章 讲解 常见 的 查询 变换 , 分别 是 子 查 询 非 幅 套 、 视 图 合并 和 谓词 推 入 。 如 果 要 对 复杂 
的 SQL (包含 各 种 子 查 询 的 SQL) 进行 优化 ， 读 者 就 必须 掌握 查询 变换 技巧 。 

第 8 章 讲 解 各 种 优化 技巧 ， 其 中 涵盖 分 页 语句 优化 思想 、 分 析 函 数 减少 表 扫 描 次 数 、 超 大 
表 与 超大 表 关 联 优化 方法 、dblink 优化 思路 ， 以 及 大 表 的 rowid 切片 优化 技巧 。 掌 握 这 些 调 优 
技巧 往往 能 够 事半功倍 。 


= 
ИШ 


第 9 章 分 享 在 SQL 优化 实战 中 遇 到 的 经 典 案 例 ,读者 可 以 在 欣赏 SQL 优化 案例 的 同时 学 
习 罗 老师 多 年 专职 SQL 优化 的 经 验 ， 同 时 学 到 很 多 具有 实战 意义 的 优化 思想 以 及 优化 方法 与 
技巧 。 

第 10 章 讲解 全 自动 SQL 审核 ， 将 有 性 能 问题 的 SQL 扼杀 在 “ 摇 锯 ”里 ,确保 系 统 上 线 
之 后 ， 不 会 因为 SQL 写法 导致 性 能 问题 ， 同 时 还 能 抓 出 不 符合 SQL 编码 规范 但 是 已 经 上 线 的 
SQL。 

本 书 对 系统 面临 性 能 压力 挑战 的 一 线 工程 师 、 运 维 工 程 师 、 数 据 库 管理 员 (DBA)、 系 统 
设计 与 开发 人 员 ， 具 有 极 大 的 参考 价值 。 

为 了 满足 不 同 层次 的 读者 需求 , 本 书 在 写作 的 内 容 上 尽量 由 浅 入 深 ,前 5 章 比较 浅显 易 懂 ， 
适合 SQL 优化 初学 者 阅读 。 通 读 完 前 5 章 之 后 ， 初 学 者 能 够 对 SQL 优化 有 一 定 认识 。 后 5 章 
属于 进 阶 和 高 级 内 容 ， 适合 有 一 定 基 础 的 人 阅读 。 通读 完 后 5 章 的 内 容 之 后 ,无 论 是 初学 者 或 
是 有 一 定 基础 的 读者 都 能 从 中 获 益 良 多 。 

本 书 专注 于 SQL 优化 技巧 ， 因 此 书 中 不 会 涉及 太 多 数据 库 系 统 优化 的 内 容 。 

虽然 本 书 是 基于 Oracle 编写 的 ， 但 是 关系 型 数据 库 的 优化 方法 都 殊途同归 ， 因 此 无 论 是 
DB2 从 业者 、SQL SERVER 从 业者 、MYSQL 从 业者 ， 亦 或 是 PostGre SQL 从 业者 等 ， 都 能 
本 书 中 学 到 所 需要 的 SQL 优化 知识 。 

因 水 平 有 限 ， 本 书 在 编写 过 程 中 难免 有 错漏 之 处 ， 恳 请 读者 批评 、 指 正 。 联 系 我 们 的 方式 
如 下 : 692162374@qq.com (QQ 好 友 数 已 达 上 限 ) 或 者 327165427@qq.com CHF QQ 账号 )。 

如 果 有 读者 想 进一步 学 习 SQL 优化 技能 或 者 一 些 公司 或 机 构 需要 开展 SQL 优化 方面 的 培 
训 ， 都 可 以 联系 作者 。 另 外 ， 作 者 还 开设 了 实体 培训 班 ， 可 以 实现 零 基础 学 习 ， 结 业 后 可 以 顺 
利 就 业 ， 欢 迎 联 系 罗 老师 。 
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在 阅读 本 书 之 前 请 读者 安装 好 Oracle 数据 库 并 且 配 置 好 示例 账户 Scott， 因 为 本 书 均 以 
Scott 账户 进行 讲解 。 推 荐 读者 安装 与 本 书 相同 版 本 的 数据 库 进 行 测试 ， 具 有 专 研 精 神 的 读者 
请 安装 好 Oraclel2c 进行 对 比 实验 ， 这 样 一 来 ， 你 将 发 现 Oraclel2c СВО 的 一 些 新 特征 。 本 书 
使 用 的 版 本 是 OraclellgR2。 

SQL» select * from v$version Where rownum=l; 


BANNER 


Oracle Database 119 Enterprise Edition Release 11.2.0.1.0 - Production 


SQL» show user 
USER Xs "Бүз" 


SQL» grant dba to scott; 

Grant succeeded. 

SQL» alter user scott account unlock; 

User altered. 

SQL» alter user scott identified by tiger; 
User altered. 


SOL» conn scott/tiger 
Connected. 


SOL» create table test as select * from dba objects; 


Table created. 
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某 个 列 唯一 键 (Distinct Keys) 的 数量 叫 作 基 数 。 比 如 性 别 列 ， 该 列 只 有 男女 之 分 ， 所 以 
这 一 列 基数 是 2。 主键 列 的 基数 等 于 表 的 总 行 数 。 基 数 的 高 低 影响 列 的 数据 分 布 。 
以 测试 表 test 为 例 ，owner 列 和 object id 列 的 基数 分 别 如 下 所 示 。 


SQL» select count (distinct owner),count (distinct object id),count(*) from test; 





COUNT(DISTINCTOWNER) COUNT(DISTINCTOBJECT ID) COUNT (*) 


29 72462 72462 


TEST 表 的 总 行 数 为 72462, owner 列 的 基数 为 29， 说 明 owner 列 里 面 有 大 量 重复 值 ， 
object id 列 的 基数 等 于 总 行 数 ， 说 明 object id 列 没有 重复 值 ， 相 当 于 主键 。owner 列 的 数据 分 
布 如 下 。 


SQL» select owner,count(*) from test group by owner order by 2 desc; 


OWNER COUNT (*) 
sys 30808 
PUBLIC 27699 
SYSMAN 3491 
ORDSYS 2532 
APEX_030200 2406 
MDSYS 1509 
хрв 844 
OLAPSYS 719 
SYSTEM 529 
CTXSYS 366 
WMSYS 316 
EXFSYS 310 
SH 306 
ORDDATA 248 
ОЕ 127 
DBSNMP 57 
IX 55 
HR 34 
PM 27 
FLOWS FILES 12 
OWBSYS AUDIT 12 
ORDPLUGINS 10 
OUTLN 9 
BI 8 
SI INFORMTN SCHEMA 8 
ORACLE OCM 8 
SCOTT 7 


| APPQOSSYS 3 
OWBSYS 2 


owner 列 的 数据 分 布 极 不 均衡 ， 我 们 运行 如 下 SQL. 


l select * from test where owner='SYS'; 


SYS 有 30808 条 数据 ， 从 72462 条 数据 里 面 查询 30 808 条 数据 ， 也 就 是 说 要 返回 表 中 
42.5% 的 数据 。 
SQL» select 30808/72462*100 "Percent" from dual; 


42.5160774 


那么 请 思考 ， 你 认为 以 上 查询 应 该 使 用 索引 吗 ? 现在 我 们 换 一 种 查询 语句 。 


| select * from test where owner-'SCOTT'; 


SCOTT 有 7 条 数据 ， 从 72 462 条 数据 里 面 查询 7 条 数据 ， 也 就 是 说 要 返回 表 中 0.00994 
的 数据 。 
SOL» select 7/72462*100 "Percent" from dual; 


Percent 


.009660236 


请 思考 ， 返 回 表 中 0.009% 的 数据 应 不 应 该 走 索 引 ? 

如 果 你 还 不 懂 索 引 ， 没 关系 ， 后 面 的 章节 我 们 会 详细 介绍 。 如 果 你 回答 不 了 上 面 的 问题 ， 
我 们 先 提醒 一 下 。 当 查询 结果 是 返回 表 中 5% 以 内 的 数据 时 ， 应 该 走 索引 ， 当 查询 结果 返回 的 
是 超过 表 中 $% 的 数据 时 ， 应 该 走 全 表 扫 描 。 

当然 了 ， 返 回 表 中 5% 以 内 的 数据 走 索引 ， 返 回 超过 5% 的 数据 就 使 用 全 表 扫 描 ， 这 个 结 
论 太 绝对 了 ， 因 为 你 还 没 掌握 后 面 章节 的 知识 ， 这 里 暂且 记 住 5% 这 个 界限 就 行 。 我 们 之 所 以 
在 这 里 讲 5%， 是 怕 一 些 初学 者 不 知道 上 面 问题 的 答案 而 纠结 。 

现在 有 如 下 查询 语句 。 


| select * from test where owner-:B1; 


语句 中 ,“:B1” 是 绑 定 变量 ， 可 以 传 入 任意 值 ， 该 查询 可 能 走 索引 也 可 能 走 全 表 扫 描 。 

现在 得 到 一 个 结论 : 如 果 某 个 列 基 数 很 低 ， 该 列 数据 分 布 就 会 非常 不 均衡 ， 由 于 该 列 数据 
分 布 不 均衡 ， 会 导致 SQL 查询 可 能 走 索 引 ， 也 可 能 走 全 表 扫 描 。 在 做 SQL 优化 的 时 候 ， 如 果 
怀疑 列 数 据 分 布 不 均衡 ， 我 们 可 以 使 用 select 列 ，count(*) from Ж group by 列 order by 2 desc 
来 查看 列 的 数据 分 布 。 

如 果 SQL 语句 是 单 表 访 问 ， 那 么 可 能 走 索 引 ， 可 能 走 全 表 扫 描 ， 也 可 能 走 物 化 视图 扫描 。 
在 不 考虑 有 物化 视图 的 情况 下 ， 单 表 访 问 要 么 走 索引 ， 要 么 走 全 表 扫 描 。 现在 ,回忆 一 下 走 索 
引 的 条 件 : 返回 表 中 $% 以 内 的 数据 走 索引 ， 超 过 5% 的 时 候 走 全 表 扫 描 。 相 信 大 家 读 到 这 里 ， 
已 经 搞 懂 了 单 表 访问 的 优化 方法 。 
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我 们 来 看 如 下 查询 。 


| select * from test where object id-:B1; 


不 管 object id 传 入 任何 值 ， 都 应 该 走 索引 。 
我 们 再 思考 如 下 查询 语句 。 


| select * from test where object папе-:В1; 


不 管 给 object_name 传 入 任何 值 ， 请 问 该 查询 应 该 走 索引 吗 ? 
请 你 去 查看 object name 的 数据 分 布 。 写 到 这 里 , 其 实 有 点 想 把 本 节 名 称 改 为 “数据 分 布 ”。 
大 家 在 以 后 的 工作 中 一 定 要 注意 列 的 数据 分 布 ! 


基数 与 总 行 数 的 比值 再 乘 以 100% 就 是 某 个 列 的 选择 性 。 

在 进行 SQL 优化 的 时 候 ， 单 独 看 列 的 基数 是 没有 意义 的 ， 基 数 必须 对 比 总 行 数 才 有 实际 
意义 ， 正 是 因为 这 个 原因 ， 我 们 才 引 出 了 选择 性 这 个 概念 。 

下 面 我 们 查看 test 表 各 个 列 的 基数 与 选择 性 ， 为 了 查看 选择 性 ， 必 须 先 收集 统计 信息 。 关 
于 统计 信息 ， 我 们 在 第 2 章 会 详细 介绍 。 下 面 的 脚本 用 于 收集 test 表 的 统计 信息 。 





SOL» BEGIN 
2 DBMS STATS.GATHER TABLE STATS (ownname => "СОТТУ 
3 tabname = UTEST!, 
4 estimate percent -» 100, 
5 method opt => 'for all columns size I', 
6 no invalidate -» FALSE, 
+ degree => 1, 
8 cascade => TRUE); 
9 END; 
10 7 


PL/SQL procedure successfully completed. 


下 面 的 脚本 用 于 查看 test 表 中 每 个 列 的 基数 与 选择 性 。 


SQL> select a.column_name, 


2 b.num rows, 

3 a.num distinct Cardinality, 

4 round(a.num distinct / b.num rows * 100, 2) selectivity, 

5 a.histogram, 

6 a.num buckets 

7 from dba tab col statistics a, dba tables b 

8 where a.owner = b.owner 

9 and a.table name = b.table name 

10 and a.owner = 'SCOTT' 

1i and a.table name - 'TEST'; 
COLUMN NAME NUM ROWS CARDINALITY SELECTIVITY HISTOGRAM NUM BUCKETS 
OWNER 72462 29 .04 NONE Ji 
OBJECT_NAME 72462 44236 61.05 NONE 1 
SUBOBJECT NAME 72462 106 .15 NONE 1 
OBJECT ID 72462 72462 100 NONE 1 


ШП пиш ж 


DATA OBJECT ID 72462 7608 10.5 NONE 1 
OBJECT TYPE 72462 44 .06 NONE 1 
CREATED 72462 1366 1.89 NONE 1 
LAST DDL TIME 72462 1412 1.95 NONE T 
TIMESTAMP 72462 1480 2.04 NONE 1 
STATUS 72462 1 0 NONE 1 
TEMPORARY 72462 2 0 МОМЕ 1 
GENERATED 72462 2 0 NONE 1 
SECONDARY 72462 2 0 NONE 1 
NAMESPACE 72462 21 .03 NONE 1 
EDITION NAME 72462 0 0 NONE 0 


15 rows selected. 


请 思考 : 什么 样 的 列 必须 建立 索引 呢 ? 

有 人 说 基数 高 的 列 , 有 人 说 在 where 条 件 中 的 列 。 这 些 答 案 并 不 完美 .基数 高 究竟 是 多 高 ? 
没有 和 总 行 数 对 比 , 始终 不 知道 有 多 高 。 比 如 某 个 列 的 基数 有 几 万 行 , 但 是 总 行 数 有 几 十 亿 行 ， 
那么 这 个 列 的 基数 还 高 吗 ? 这 就 是 要 引出 选择 性 的 根本 原因 。 

当 一 个 列 选择 性 大 于 20%, 说 明 该 列 的 数据 分 布 就 比较 均衡 了 .测试 表 test 中 object пате. 
object id 的 选择 性 均 大 于 2096, 其 中 object name 列 的 选择 性 为 61.05%。 现在 我 们 查看 该 列 数 
据 分 布 〈“ 为 了 方便 展示 ， 只 输出 前 ТО 行 数据 的 分 布 情况 )。 


SQL> select * 
2 from (select object_name, count(*) 
3 from test 
4 group by object_name 
5 order by 2 desc) 
6 where rownum <= 10; 


OBJECT NAME COUNT (*) 
COSTS 30 
SALES 30 
SALES CHANNEL BIX 29 
COSTS TIME BIX 29 
COSTS PROD BIX 29 
SALES TIME BIX 29 
SALES PROMO BIX 29 
SALES PROD BIX 29 
SALES CUST BIX 29 
DBMS REPCAT AUTH 5 


10 rows selected. 


由 上 面 的 查询 结果 我 们 可 知 ，object_name 列 的 数据 分 布 非常 均衡 。 我 们 查询 以 下 SQL. 


| select * from test where object_name=:B1; 


АЁ object пате 传 入 任何 值 ， 最 多 返回 30 行 数 据 。 

什么 样 的 列 必 须要 创建 索引 呢 ? 当 一 个 列 出 现在 where 条 件 中 , 该 列 没有 创建 索引 并 且 选 
择 性 大 于 20%， 那 么 该 列 就 必须 创建 索引 ， 从 而 提升 SQL 查询 性 能 。 当 然 了 ， 如 果 表 只 有 几 
百 条 数据 ， 那 我 们 就 不 用 创建 索引 了 。 

下 面 抛 出 SQL 优化 核心 思想 第 一 个 观点 : 只 有 大 表 才 会 产生 性 能 问题 。 

也 许 有 人 会 说 :“ 我 有 个 表 很 小 ， 只 有 几 百 条 ， 但 是 该 表 经 常 进行 DML， 会 产生 热点 块 ， 
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也 会 出 性 能 问题 。 “对 此 我 们 并 不 想 过 多 地 讨论 此 问题 , 这 属于 应 用 程序 设计 问题 , 不 属于 SQL 
优化 的 范畴 。 

下 面 我 们 将 通过 实验 为 大 家 分 享 本 书 第 一 个 全 自动 优化 脚本 。 

抓 出 必须 创建 索引 的 列 ( 请 读者 对 该 脚本 适当 修改 ， 以 便 用 于 生产 环境 )。 

首先 ， 该 列 必 须 出 现在 where 条 件 中 ,怎么 抓 出 表 的 哪个 列 出 现在 where 条 件 中 呢 ? 有 两 
种 方法 ， 一 种 是 可 以 通过 V$SQL PLAN 抓 取 ， 另 一 种 是 通过 下 面 的 脚本 抓 取 。 

先 执 行 下 面 的 存储 过 程 ， 刷 新 数据 库 监控 信息 。 

begin 


dbms stats.flush database monitoring info; 
end; 


运行 完 上 面 的 命令 之 后 ， 再 运行 下 面 的 查询 语句 就 可 以 查询 出 哪个 表 的 哪个 列 出 现在 
where 条 件 中 。 


select r.name owner, 
o.name table_name, 
c.name column name, 
equality preds，--- 等 值 过 滤 


equijoin preds, --- Ü JOIN 比如 where a.id-b.id 
nonequijoin preds, ---- 1 JOIN 

range_preds, ---- 范 围 过 滤 次 数 > >= < <= between and 
like preds, ----LIKE dj 

null preds, ----NULL 过 滤 

timestamp 


from sys.col usage$ u, sys.obj$ o, sys.col$ c, sys.user$ r 


where o.obj# = u.obj# 
and c.obj# = u.obj# 
and c.col# = u.intcol# 
and r.name = 'SCOTT' 
and o.name = 'TEST'; 
下 面 是 实验 步骤 。 


我 们 首先 运行 一 个 查询 语句 ， 让 owner 与 object id 列 出 现在 where 条 件 中 。 


SOL» select object id, owner, object type 


2 from test 

3 where owner - 'SYS' 

4 and object id « 100 

5 and rownum «- 10; 

OBJECT ID OWNER OBJECT TYPE 
2D Sra TABLE 
46 SYS INDEX 
28 SYS TABLE 
18 8Ү8 TABLE 
29 SYS CLUSTER 
3 SYS INDEX 

25 SYS TABLE 
41 SYS INDEX 
54 SYS INDEX 
40 SYS INDEX 


10 rows selected. 
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其 次 刷新 数据 库 监 控 信 息 。 


SQL» begin 
2 dbms stats.flush database monitoring info; 
2. vost 
4 


PL/SQL procedure successfully completed. 


然后 我 们 查看 test 表 有 哪些 列 出 现在 where 条 件 中 。 


SQL> select r.name owner, o.name table name, c.name column name 
2 from sys.col usage$ u, sys.obj$ o, sys.col$ c, sys.user$ г 


3 where o.obj# = u.obj# 

4 and c.obj# = u.obj# 

5 and c.col# = u.intcolf 

6 and r.name = 'SCOTT' 

7 and o.name = 'TEST'; 
OWNER TABLE NAME COLUMN NAME 
SCOTT TEST OWNER 
SCOTT TEST OBJECT ID 


接 下 来 我 们 查询 出 选择 性 大 于 等 于 20% 的 列 。 


SQL> select a.owner, 
a.table name, 
a.column name, 
round(a.num distinct / b.num rows * 100, 2) selectivity 
from dba tab col statistics a, dba tables b 
where a.owner = b.owner 
and a.table name = b.table name 
and a.owner — 'SCOTT' 
and a.table name - 'TEST' 
and a.num distinct / b.num rows »- 0.2; 


© хо 0 м] сул > (O N 


= 


OWNER TABLE NAME COLUMN NAME SELECTIVITY 


SCOTT TEST OBJECT NAME 61.05 
SCOTT TEST OBJECT ID 100 


最 后 ， 确 保 这 些 列 没有 创建 索引 。 


SQL» select table owner, table name, column name, index name 


2 from dba ind columns 

3 where table owner - 'SCOTT' 

4 and table name - 'TEST'; 
未 选 定 行 


把 上 面 的 脚本 组 合 起 来 ， 我 们 就 可 以 得 到 全 自动 的 优化 脚本 了 。 


SOL» select owner, 
column name, 
num rows, 
Cardinality, 
selectivity, 
'Need index' as notice 
from (select b.owner, 
a.column name, 
b.num rows, 


O со — суол > (Q [SN 


13 直方 图 ( HISTOGRAM ) 


10 a.num distinct Cardinality, 

11 round(a.num_distinct / b.num_rows * 100, 2) selectivity 
12 from dba tab col statistics a, dba tables b 

13 where a.owner = b.owner 

14 and a.table name - b.table name 

15 and a.owner = 'SCOTT' 

16 and a.table name = 'TEST') 

17 where selectivity »- 20 

18 and column name not in (select column name 

19 from dba ind columns 

20 where table owner = 'SCOTT' 

21 and table name - 'TEST') 

22 and column name in 

23 (select c.name 

24 from sys.col usage$ u, sys.obj$ o, sys.col$ c, sys.user$ r 
25 where o.obj# = u.obj# 

26 and c.obj# = u.obj# 

27 and c.col# = u.intcol# 

28 and r.name = 'SCOTT' 

29 and o.name = 'TEST'); 
OWNER COLUMN NAME NUM ROWS CARDINALITY SELECTIVITY NOTICE 
SCOTT OBJECT ID 72462 72462 100 Need index 
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前 面 提 到 ， 当 某 个 列 基 数 很 低 ， 该 列 数据 分 布 就 会 不 均衡 。 数 据 分 布 不 均衡 会 导致 在 查询 
该 列 的 时 候 ， 要 么 走 全 表 扫 描 ， 要 么 走 索引 扫描 ， 这 个 时 候 很 容易 走 错 执行 计划 。 

如 果 没 有 对 基数 低 的 列 收集 直方 图 统计 信息 ， 基 于 成 本 的 优化 器 ( CBO ) 会 认为 该 列 数 
据 分 布 是 均衡 的 。 

下 面 我 们 还 是 以 测试 表 test 为 例 ， 用 实验 讲解 直方 图 。 

首先 我 们 对 测试 表 test 收集 统计 信息 ， 在 收集 统计 信息 的 时 候 ， 不 收集 列 的 直方 图 ， 语 名 
for all columns size 1 表示 对 所 有 列 都 不 收集 直方 图 。 


SQL» BEGIN 
2 DBMS STATS.GATHER TABLE STATS (ownname => ТӘСІЛ”, 
3 tabname => 'TEST', 
4 estimate percent -» 100, 
5 method opt => "for all columns size 1", 
6 no invalidate => FALSE, 
7 degree => 1, 
8 cascade => TRUE); 
9 END; 
ШИ 


PL/SQL procedure successfully completed. 


Histogram 为 none 表示 没有 收集 直方 图 。 


SOL» select a.column name, 


2 b.num rows, 

3 a.num distinct Cardinality, 

4 round(a.num distinct / b.num rows * 100, 2) selectivity, 
5 a.histogram, 


6 a.num buckets 
7 from dba tab col statistics a, dba tables b 
8 where a.owner - b.owner 
9 and a.table name = b.table name 

10 and a.owner = 'SCOTT' 

11 and a.table name - 'TEST'; 
COLUMN NAME NUM ROWS CARDINALITY SELECTIVITY HISTOGRAM NUM BUCKETS 
OWNER 72462 29 .04 NONE 1 
OBJECT NAME 72462 44236 61.05 NONE 1 
SUBOBJECT_NAME 72462 106 .15 NONE 1, 
OBJECT_ID 72462 72462 100 NONE 1 
DATA OBJECT ID 72462 7608 10.5 NONE 1 
OBJECT TYPE 72462 44 .06 NONE 1 
CREATED 72462 1366 1.89 NONE 1 
LAST DDL TIME 72462 1412 1.95 NONE 1 
TIMESTAMP 72462 1480 2.04 NONE 1 
STATUS 72462 1 0 NONE 1 
TEMPORARY 72462 2 0 NONE 1 
GENERATED 72462 2 0 NONE 1 
SECONDARY 72462 2 0 NONE 1 
NAMESPACE 72462 21 .03 NONE 1 
EDITION NAME 72462 0 0 NONE 0 
15 rows selected. 

owner 列 基 数 很 低 ， 现 在 我 们 对 owner 列 进行 查询 。 
SQL> set autot trace 
SOL» select * from test where ownerz'SCOTT'; 
7 rows selected. 
Execution Plan 

Plan hash value: 1357081020 

| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time | 
| 0 | SELECT STATEMENT | | 2499 | 236K| 289 (1)1 00:00:04 | 
|%1 | TABLE ACCESS FULL| TEST | 2499 | 236K| 289 (1) | 00:00:04 | 


1 - filter("OWNER"-'SCOTT') 


请 注意 看 粗 体 字 部 分 ， 查 询 owner 二 'SCOTT' 返 回 了 7 条 数据 ， 但 是 CBO 在 计算 Rows 的 
时 候 认为 owner='SCOTT' 返 回 2499 条 数据 ，Rows 估算 得 不 是 特别 准确 。 从 72 462 条 数据 
里 面 查询 出 7 条 数据 ， 应 该 走 索 引 ， 所 以 现在 我 们 对 owner 列 创建 索引 。 


SQL» create index idx owner on test (owner); 


Index created. 


我 们 再 来 查询 一 下 。 
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SQL> select * from test where owner='SCOTT'; 
7 rows selected. 
Execution Plan 


Plan hash value: 3932013684 


| Id |Operation | Name | Rows | Bytes | Cost($CPU)| Time 

| 0 | SELECT STATEMENT | | 2499 | 236К | 73 (0) | 00:00:01 

| 1 | TABLE ACCESS BY INDEX ROWID |ТЕ5Т | 2499 | 236К | 33 (0)| 00:00:01 
|* 2 | INDEX RANGE SCAN |IDX OWNER| 2499 | | 6 (0)| 00:00:01 | 


2 - access ("OWNER"-'SCOTT') 
现在 我 们 查询 owner-'svs'. 
SOL> select * from test where owner='SYS'; 
30808 rows selected. 
Execution Plan 


Plan hash value: 3932013684 


| Id |Operation | Name | Rows | Bytes | Cost($CPU)| Time 

| 0 | SELECT STATEMENT | | 2499 | 236К| 73 (0) | 00:00:01 | 
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 2499 | 236K| T3 СОХ 00:00:01 | 
|% 2 | INDEX RANGE 5САМ | IDX ОЙМЕК| 2499 | | 6 (0) | 00ғ00:01 | 


2 — access ("OWNER"='SYS') 


注意 粗 字 体 部 分 ， 查 询 owner='SYS' 返 回 了 30 808 条 数据 。 从 72 462 条 数据 里 面 返回 
30 808 条 数据 能 走 索 引 吗 ? 很 明显 应 该 走 全 表 扫 描 。 也 就 是 说 该 执行 计划 是 错误 的 。 
为 什么 查询 ownez='SYS ' 的 执行 计划 会 用 错 呢 ? 因为 owner 这 个 列 基数 很 低 ， 只 有 29, 
而 表 的 总 行 数 是 72 462。 前 文 着 重 强调 过 ， 当 列 没有 收集 直方 图 统计 信息 的 时 候 ，CBO 会 认 
为 该 列 数据 分 布 是 均衡 的 。 正 是 因为 CBO 认为 owner 列 数 据 分 布 是 均衡 的 ， 不 管 owner 等 于 
任何 值 ，CBO 估算 的 Rows 永远 都 是 2 499。 而 这 2499 是 怎么 来 的 呢 ? 答案 如 下 。 
SQL> select round(72462/29) from dual; 


round(72462/29) 


现在 大 家 也 知道 了 ， 执 行 计划 里 面 的 Rows 是 假 的 。 执 行 计 划 中 的 Rows 是 根据 统计 信息 
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以 及 一 些 数学 公式 计算 出 来 的 。 很 多 DBA 到 现在 还 不 知道 执行 计划 中 Rows 是 假 的 这 个 真相 ， 
真是 令 人 遗憾 。 

在 做 SQL 优化 的 时 候 , 经 常 需要 做 的 工作 就 是 帮助 СВО 计算 出 比较 准确 的 Rows. 注意 : 
我 们 说 的 是 比较 准确 的 Rows。CBO 是 无 法 得 到 精确 的 Rows 的 ， 因 为 对 表 收 集 统 计 信 息 的 时 
候 ， 统 计 信息 一 般 都 不 会 按照 100% 的 标准 采样 收集 ， 即 使 按照 100% 的 标准 采样 收集 了 表 的 
统计 信息 , 表 中 的 数据 也 随时 在 发 生变 更 。 另 外 计算 Rows 的 数学 公式 目前 也 是 有 缺陷 的 , СВО 
永远 不 可 能 计算 得 到 精确 的 Rows。 

ШЕ СВО 每 次 都 能 计算 得 到 精确 的 Rows， 那 么 相信 我 们 这 个 时 候 只 需要 关心 业务 逻辑 、 
表 设 计 、SQL 写法 以 及 如 何 建立 索引 了 ， 再 也 不 用 担心 SQL 会 走 错 执行 计划 了 。 

Oraclel2c 的 新 功能 SQL Plan Directives 在 一 定 程度 上 解决 了 Rows 估算 不 准 而 引发 的 SQL 
性 能 问题 。 关 于 SQL Plan Directives， 本 书 不 做 过 多 讨论 。 

为 了 让 СВО 选择 正确 的 执行 计划 , 我 们 需要 对 owner 列 收集 直方 图 信息 ， 从 而 告知 СВО 
该 列 数据 分 布 不 均衡 ， 让 СВО 在 计算 Rows 的 时 候 参 考 直方 图 统计 。 现 在 我 们 对 owner 列 收 
集 直方 图 。 


SQL> BEGIN 

2 DBMS STATS.GATHER TABLE STATS (ownname => 'SCOTT', 

Ej tabname => 'TEST', 

4 estimate percent -» 100, 

5 method opt => 'for columns owner size skewonly', 
6 no invalidate => FALSE, 

7 degree => 1, 

8 cascade => TRUE); 

9 END; 
10: Z 


PL/SQL procedure successfully completed. 


查看 一 下 owner 列 的 直方 图 信息 。 


SQL» select a.column name, 


2 b.num rows, 

3 a.num distinct Cardinality, 

4 round(a.num distinct / b.num rows * 100, 2) selectivity, 

5 a.histogram, 

6 a.num buckets 

7 from dba tab col statistics a, dba tables b 

8 where a.owner - b.owner 

9 and a.table name - b.table name 

10 and a.owner = 'SCOTT' 

11 and a.table name = 'TEST'; 
COLUMN NAME NUM ROWS CARDINALITY SELECTIVITY HISTOGRAM МОМ BUCKETS 
OWNER 72462 29 .04 FREQUENCY 29 
OBJECT NAME 72462 44236 61.05 NONE 1 
SUBOBJECT NAME 72462 106 .15 NONE 1 
OBJECT_ID 72462 72462 100 NONE 1 
DATA OBJECT ID 72462 7608 10.5 NONE T 
OBJECT TYPE 72462 44 .06 NONE 1 
CREATED 72462 1366 1.89 NONE 1 
LAST DDL TIME 72462 1412 1.95 NONE 1 


13 直方 图 ( HISTOGRAM ) 


TIMESTAMP 72462 1480 2.04 NONE 1 
STATUS 72462 1 0 NONE 1 
TEMPORARY 72462 2 0 NONE 1 
GENERATED 72462 2 0 NONE 1 
SECONDARY 72462 2 0 NONE 1 
NAMESPACE 72462 21 .03 NONE 1, 
EDITION МАМЕ 72462 0 0 МОМЕ 0 


15 rows selected. 
现在 我 们 再 来 查询 上 面 的 SQL， 看 执行 计划 是 否 还 会 走 错 并 且 验 证 Rows 是 否 还 会 算 错 。 
501> select * from test where owner='SCOTT'; 
7 rows selected. 
Execution Plan 


Plan hash value: 3932013684 


| Та |Орегабіоп | Name | Rows | Bytes | Cost (%CPU)| Time 

| 0 | SELECT STATEMENT | | » 679 | 2 (0) 1 00:00:01 

| 1 | TABLE ACCESS BY INDEX ROWID| TEST | A 679 | 2 (0)] 00:00:01 
|* 2 | INDEX RANGE SCAN | IDX OWNER| 71 | 1 (0)] 00:00:01 | 


2 - access ("OWNER"-'SCOTT') 
SQL» select * from test where owner-'SYS'; 
30808 rows selected. 
Execution Plan 


Plan hash value: 1357081020 


| Id | Operation | Name | Rows | Bytes | Cost (%СРО) | Time 
| 0 | SELECT STATEMENT | | 30808 | 2918K| 290 (1)| 00:00:04 | 
I* 1 | TABLE ACCESS FULL| TEST | 30808 | 2918K] 290 (1)] 00:00:04 | 


1 - filter("OWNER"-'SYS') 


对 owner 列 收集 完 直 方 图 之 后 ，CBO 估算 的 Rows 就 基本 准确 了 ， 一 旦 Rows 估算 对 了 ， 
那么 执行 计划 也 就 不 会 出 错 了 。 

大 家 是 不 是 很 好 奇 ， 为 什么 收集 完 直 方 图 之 后 ，Rows 计算 得 那么 精确 ， 收 集 直 方 图 究竟 
完成 了 什么 操作 呢 ? 对 owner 列 收集 直方 图 其 实 就 相当 于 运行 了 以 下 SQL. 


| select owner,count(*) from test group by owner; 


ccom i o o SAMNENENNNNENN- «uU 

直方 图 信息 就 是 以 上 SQL 的 查询 结果 ， 这 些 查 询 结果 会 保存 在 数据 字典 中 。 这 样 当 我 们 
查询 owner 为 任意 值 的 时 候 ，CBO 总 会 算出 正确 的 Rows， 因 为 直方 图 已 经 知道 每 个 值 有 多 少 
行 数据 。 

WMR SQL 使 用 了 绑 定 变量 ， 绑 定 变 量 的 列 收集 了 直方 图 ,那么 该 SQL 就 会 引起 绑 定 变量 
帘 探 。 绑 定 变 量 帘 探 是 一 个 老生 常 谈 的 问题 ， 这 里 不 多 做 讨论 。Oraclellg 引入 了 自 适应 游标 
共享 (Adaptive Cursor Sharing)， 基 本 上 解决 了 绑 定 变量 完 探 问题 ， 但 是 自 适 应 游标 共享 也 会 
引起 一 些 新 闻 题 ， 对 此 也 不 做 过 多 讨论 。 

当 我 们 遇 到 一 个 SQL 有 绑 定 变量 怎么 办 ? 其 实 很 简单 ， 我 们 只 需要 运行 以 下 语句 。 


І select 2], count(*) from test group by 列 order by 2 desc; 


如 果 列 数据 分 布 均 衡 ， 基 本 上 SQL 不 会 出 现 问题 ， 如果 列 数据 分 布 不 均衡 ， 我 们 需要 对 
列 收集 直方 图 统计 。 

关于 直方 图 ， 其 实 还 有 非常 多 的 话题 ， 比 如 直方 图 的 种 类 、 直 方 图 的 桶 数 等 ， 本 书 在 此 不 
做 过 多 讨论 。 在 我 们 看 来 ， 读 者 只 需要 知道 直方 图 是 用 来 帮助 СВО 在 对 基数 很 低 、 数 据 分 布 
不 均衡 的 列 进行 Rows 估算 的 时 候 ， 可 以 得 到 更 精确 的 Rows 就 够 了 。 

什么 样 的 列 需要 收集 直方 图 呢 ? 当 列 出 现在 where 条 件 中 ， 列 的 选择 性 小 于 1% 并 且 该 
列 没有 收集 过 直方 图 ， 这 样 的 列 就 应 该 收集 直方 图 。 注意: 干 万 不 能 对 没有 出 现在 where 条 
件 中 的 列 收集 直方 图 。 对 没有 出 现在 where 条 件 中 的 列 收集 直方 图 完全 是 做 无 用 功 ， 浪 费 数 
据 库 资 源 。 

下 面 我 们 为 大 家 分 享 本 书 第 二 个 全 自动 化 优化 脚本 。 

抓 出 必须 创建 直方 图 的 列 ( 大 家 可 以 对 该 脚本 进行 适当 修改 ， 以 便 用 于 生产 环境 )。 


SOL» select a.owner, 
2 a.table name, 
3 a.column name, 
4 b.num rows, 
5 a.num distinct, 
6 trunc(num distinct / num rows * 100,2) selectivity, 
7 'Need Gather Histogram' notice 
8 from dba tab col statistics a, dba tables b 


9 where a.owner - 'SCOTT' 
10 and a.table name - 'TEST' 
11 and a.owner = b.owner 
12 and a.table name = b.table name 
13 and num distinct / num rows«0.01 
14 and (a.owner, a.table name, a.column name) in 
15 (select r.name owner, o.name table name, c.name column name 
16 from sys.col Usage$ u, sys.obj$ o, sys.col$ c, sys.user$ r 
TJ where o.obj4 = u.objt 
18 and c.obj$ = u.objtt 
19 апа c.col# = u.intcol# 
20 and r.name = '5СОТТ' 
21 and o.name = 'TEST') 
22 and a.histogram -'NONE'; 


OWNER TABLE COLUM NUM ROWS NUM DISTINCT SELECTIVITY NOTICE 


SCOTT TEST OWNER 72462 29 .04 Need Gather Histogram 


1.44 EX (TABLE ACCESS BY INDEX ROWID ) 


т | TUI | | | 
n 





当 对 一 个 列 创建 索引 之 后 ， 索 引 会 包含 该 列 的 键 值 以 及 键 值 对 应 行 所 在 的 rowid. 383b 
引 中 记录 的 rowid 访问 表 中 的 数据 就 叫 回 表 。 回 表 一 般 是 单 块 读 ， 回 表 次 数 太 多 会 严重 影响 
SQL 性 能 ， 如 果 回 表 次 数 太 多 ， 就 不 应 该 走 索 引 扫描 了 ， 应 该 直接 走 全 表 扫描 。 

在 进行 SQL 优化 的 时 候 ， 一 定 要 注意 回 表 次 数 ! 特别 是 要 注意 回 表 的 物理 IO 次 数 ! 

大 家 还 记得 1.3 节 中 错误 的 执行 计划 吗 ? 

SQL» select * from test where owner-'SYS'; 


30808 rows selected. 


Execution Plan 


Plan hash value: 3932013684 


| Id | Operation | Name | Rows | Bytes | Cost($CPU)| Time | 
| 0 | SELECT STATEMENT | | 2499 | 236K| 73 (0) | 00:00:01 | 
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 2499 | 236K| 73 (0)| 00:00:01 | 
|% 2 | INDEX RANGE SCAN | IDX OWNER| 2499 | | 6 (02 | 00:00:02. | 


Predicate Information (identified Бу operation id): 


2 - access("OWNER"-'SYS') 


执行 计划 中 加 粗 部 分 CTABLE ACCESS BY INDEX ROWID) 就 是 回 表 。 索 引 返 回 多 少 行 
数据 ， 回 表 就 要 回 多 少 次， 每 次 回 表 都 是 单 块 读 〈 因 为 一 个 rowid 对 应 一 个 数据 块 )。 该 SQL 
返回 了 30 808 行 数据 ， 那 么 回 表 一 共 就 需要 30 808 次 。 

请 思考 : 上 面 执行 计划 的 性 能 是 耗费 在 索引 扫描 中 还 是 耗费 在 回 表 中 ? 

为 了 得 到 答案 , 请 大 家 在 SQLPLUS 中 进行 实验 ,为 了 消除 arraysize 参数 对 逻辑 读 的 影响 ， 
设置 arraysize=5000。arraysize 表示 Oracle 服务 器 每 次 传输 多 少 行 数 据 到 客户 端 ， 默 认为 
15。 如 果 一 个 块 有 150 行 数据 ， 那么 这 个 块 就 会 被 读 10 次 ， 因 为 每 次 只 传输 15 行 数据 到 客户 
п, 逻辑 读 会 被 放大 。 设置 了 arraysize=5000 2/8, 就 不 会 发 生 一 个 块 被 读 n 次 的 问题 了 。 

SQL> set arraysize 5000 

SQL> set autot trace 

SQL» select owner from test where owner-'SYS'; 
30808 rows selected. 

Execution Plan 


Plan hash value: 373050211 
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0 | SELECT STATEMENT | | 2499 | 14994 | 6 (0)1 00:00:01 | 
I* 1 | INDEX RANGE SCAN| IDX OWNER | 2499 | 14994 | 6 (0)| 00:00:01 | 


1 - access("OWNER"-'SYS') 


Statistics 
0 recursive calls 
0 db block gets 
74 consistent gets 
0 physical reads 
0 redo size 
155251 bytes sent via SQL*Net to client 
486 bytes received via SQL*Net from client 
8 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
30808 rows processed 


从 上 面 的 实验 可 见 ， 索 引 扫 描 只 耗费 了 74 个 逻辑 读 。 
SQL» select * from test where owner-'SYS'; 
30808 rows selected. 
Execution Plan 


Plan hash value: 3932013684 


| Id [Operation | Name | Rows | Bytes | Cost($CPU)| Time 

| 0 | SELECT STATEMENT | | 2499 | 236K| 73 (0) | 00:00:01 | 
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 2499 | 236K| 73 (0)1 00:00:01 | 
|% 2 | INDEX RANGE SCAN | IDX OWNER| 2499 | | 6 (0)1 00:00:01 | 


2 - access ("OWNER"-'SYS') 


Statistics 

0 recursive calls 
0 db block gets 

877 consistent gets 
0 physical reads 
0 redo size 

3120934 bytes sent via SQL*Net to client 

486 bytes received via SQL*Net from client 
8 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 

30808 rows processed 


1.5 集群 因子 ( CLUSTERING FACTOR ) 


SQL» set autot off 
SOL» select count(distinct dbms rowid.rowid block number(rowid)) blocks 


2 from test 
3 where owner - 'SYS'; 
BLOCKS 
796 


SQL 在 有 回 表 的 情况 下 , 一 共 耗 费 了 877 个 逻辑 读 , 那么 这 877 个 逻辑 读 是 怎么 来 的 呢 ? 

SQL 返回 的 30 808 条 数据 一 共存 储 在 796 个 数据 块 中 ， 访 问 这 796 个 数据 块 就 需要 消耗 796 
个 逻辑 读 ， 加 上 索引 扫描 的 74 个 罗 辑 读 ， 再 加 上 7 个 逻辑 读 [ 其 中 7=ROUND (30808/5000) ]， 这 
样 累计 起 来 刚好 就 是 877 个 逻辑 读 。 

因此 我 们 可 以 判断 ， 该 SQL 的 性 能 确实 绝 大 部 分 损失 在 回 表 中 ! 

更 糟糕 的 是 : 假设 30 808 条 数据 都 在 不 同 的 数据 块 中 , 表 也 没有 被 缓存 在 buffer cache 中 ， 
那么 回 表 一 共 需 要 耗费 30 808 个 物理 UO， 这 太 可 怕 了 。 

大 家 看 到 这 里 ， 是 否 能 回答 为 什么 返回 表 中 $% 以 内 的 数据 走 索 引 、 超 过 表 中 $% 的 数据 
走 全 表 扫 描 ? 根本 原因 就 在 于 回 表 。 

在 无 法 避免 回 表 的 情况 下 ， 走 索引 如 果 返 回 数据 量 太 多 ， 必 然 会 导致 回 表 次 数 太 多 ， 从 而 
导致 性 能 严重 下 降 。 

Oraclel2c 的 新 功能 批量 回 表 (TABLE ACCESS BY INDEX КОМІР BATCHED) 在 一 定 程 度 
上 改善 了 单行 回 表 (TABLE ACCESS BYINDEX ROWID) 的 性 能 。 关 于 批量 回 表 本 书 不 做 讨论 。 

什么 样 的 SQL 必须 要 回 表 ? 
| Select * from table where ... 

这 样 的 SQL 就 必须 回 表 , 所 以 我 们 必须 严禁 使 用 Select *。 那 什么 样 的 SQL 不 需要 回 表 ? 
| Select count(*) from table 

这 样 的 SQL 就 不 需要 回 表 。 

当 要 查询 的 列 也 包含 在 索引 中 , 这 个 时 候 就 不 需要 回 表 了 , 所 以 我 们 往往 会 建立 组 合 索引 
来 消除 回 表 ， 从 而 提升 查询 性 能 。 

当 一 个 SQL 有 多 个 过 滤 条 件 但 是 只 在 一 个 列 或 者 部 分 列 建立 了 索引 ， 这 个 时 候 会 发 生 回 
表 再 过 滤 (TABLE ACCESS BY INDEX ROWID 前 面 有 “*”)， 也 需要 创建 组 合 索 引 ， 进 而 消 
除 回 表 再 过 滤 ， 从 而 提升 查询 性 能 。 

关于 如 何 创建 组 合 索引 ， 这 问题 太 复杂 了 ， 我 们 在 本 书 8.3 节 、9.1 节 以 及 第 10 章 都 会 反 
复 提 及 如 何 创 建 组 合 索引 。 
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集群 因子 用 于 判断 索引 回 表 需 要 消耗 的 物理 IO 次 数 。 
我 们 先 对 测试 表 test 的 object id 列 创建 一 个 索引 idx id。 
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| SOL» create index idx id on test(object id); 


Index created. 


然后 我 们 查看 该 索引 的 集群 因子 。 


SQL» select owner, index name, clustering factor 
2 from dba indexes 
3 where owner = 'SCOTT' 
4 and index name = 'IDX ID'; 


OWNER INDEX NAME CLUSTERING FACTOR 


SCOTT IDX ID 1094 


索引 idx id 的 叶子 块 中 有 序 地 存储 了 索引 的 键 值 以 及 键 值 对 应 行 所 在 的 ROWID。 


SQL» select * from ( 
2 select object id, rowid 
3 from test 
4 where object id is not null 
5 order by object id) where rownum«-5; 


OBJECT ID ROWID 


2 AAASNJAAEAAAAITAAw 
3 AAASNJAAEAAAAITAAF 
4 AAASNJAAEAAAAITAAx 
5 AAASNJAAEAAAAITAAa 
6 AAASNJAAEAAAAITAAV 


集群 因子 的 算法 如 下 。 

首先 我 们 比较 2.3 对 应 的 ROWID 是 否 在 同一 个 数据 块 , 如 果 在 同一 个 数据 块 , Clustering 
Factor +0; 如 果 不 在 同一 个 数据 块 ， 那 么 Clustering Factor (ЕЛ 1. 

然后 我 们 比较 3、4 对 应 的 ROWID 是 否 在 同一 个 数据 块 , 如 果 在 同一 个 数据 块 , Clustering 
Factor 值 不 变 ; 如 果 不 在 同一 个 数据 块 ， 那 么 Clustering Factor 值 加 1。 

接 下 来 我 们 比较 4.5 对 应 的 ROWID 是 否 在 同一 个 数据 块 ,如 果 在 同一 个 数据 块 ,Clustering 
Factor +0; 如 果 不 在 同一 个 数据 块 ， 那 么 Clustering Factor 值 加 1. 

像 上 面 步骤 一 样 ， 一 直 这 样 有 序 地 比较 下 去 ， 直 到 比较 完 索 引 中 最 后 一 个 键 值 。 

根据 算法 我 们 知道 集群 因子 介 于 表 的 块 数 和 表 行 数 之 间 。 

如 果 集 群 因 子 与 块 数 接近 , 说 阴 表 的 数据 基本 上 是 有 序 的 , 而 且 其 顺序 基本 与 索引 顺序 一 
样 。 这 样 在 进行 索引 范围 或 者 索引 全 扫描 的 时 候 ， 回 表 只 需要 读 取 少 量 的 数据 块 就 能 完成 。 

如 果 集 群 因子 与 表 记 录 数 接近 , 说 明 表 的 数据 和 索引 顺序 差异 很 大 , 在 进行 索引 范围 扫描 
或 者 索引 全 扫描 的 时 候 ， 回 表 会 读 取 更 多 的 数据 块 。 

集群 因子 只 会 影响 索引 范围 扫描 (INDEX RANGE SCAN) 以 及 索引 全 扫描 (INDEX FULL 
SCAN)， 因 为 具有 这 两 种 索引 扫描 方式 会 有 大 量 数据 回 表 。 

集群 因子 不 会 影响 索引 唯一 扫描 CINDEX UNIQUE SCAN)， 因 为 索引 唯一 扫描 只 返回 一 
条 数据 。 集 群 因 子 更 不 会 影响 索引 快速 全 扫描 (INDEX FAST FULL SCAN)， 因 为 索引 快速 全 
扫描 不 回 表 。 


1.5 集群 因子 ( CLUSTERING FACTOR ) 


下 面 是 根据 集群 因子 算法 人 工 计 算 集 群 因子 的 SQL 脚本 。 


SQL> select sum(case ^ 
when block#1 = block#2 and file#l = file#2 then 


2 

3 0 

4 else 

5 1 

6 end) CLUSTERING FACTOR 

7 from (select dbms rowid.rowid relative fno(rowid) file#1, 

8 lead(dbms rowid.rowid relative fno(rowid), 1, null) over(order by object id) f 
ile#2, 

9 dbms_rowid.rowid block number(rowid) block#1, 

10 lead(dbms rowid.rowid block number(rowid), 1, null) over (order by object id) b 
lock#2 

11 from test 

12 where object id is not null); 


CLUSTERING FACTOR 


我 们 来 查看 索引 idx_id 的 集群 因子 接近 表 的 总 行 数 还 是 表 的 总 块 数 。 
通过 前 面 的 章节 我 们 知道 ， 表 的 总 行 数 为 72 462 行 。 
表 的 总 块 数 如 下 可 知 。 


SQL> select count (distinct dbms rowid.rowid block number (rowid)) blocks 
2 from test; 


BLOCKS 


集群 因子 非常 接近 表 的 总 块 数 。 现 在 ， 我 们 来 查看 下 面 SQL 语句 的 执行 计划 。 


SQL> set arraysize 5000 
SQL» set autot trace 
SQL» select * from test where object id « 1000; 


942 rows selected. 
Execution Plan 


Plan hash value: 3946039639 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time 

| 0 | SELECT STATEMENT | | 970 | 94090 | 19 (0)] 00:00:01 | 
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 970 | 94090 | 19 (0)! 00:00031. | 
|% 2 | INDEX RANGE SCAN | IDX ID | 970 | | 4 (0)] 00:00:01 | 


2 - access("OBJECT ID"«1000) 


Statistics 
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0 recursive calls 
0 db block gets 
17 consistent gets 
0 physical reads 
0 redo size 
86510 bytes sent via SQL*Net to client 
420 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
942 rows processed 


该 SQL 耗费 了 17 MEHE. 

现在 我 们 新 建 一 个 测试 表 test2 并 且 对 数据 进行 随机 排序 。 
SQL» create table test2 as select * from test order by dbms random.value; 
Table created. 

我 们 在 object id 列 创建 一 个 索引 idx 142. 
SQL» create index idx id2 on test2(object id); 


Index created. 


我 们 查看 索引 idx 142 的 集群 因子 。 


SOL» select owner, index name, clustering factor 


2 from dba indexes 

3 where owner - 'SCOTT' 

4 and index name - 'IDX ID2'; 
OWNER INDEX NAME CLUSTERING FACTOR 
SCOTT IDX ID2 72393 


索引 idx_id2 的 集群 因子 接近 于 表 的 总 行 数 ， 回 表 的 时 候 会 读 取 更 多 的 数据 块 ， 


来 看 一 下 SQL 的 执行 计划 。 


SQL> set arraysize 5000 
SQL» set autot trace 
SOL» select /*+ index(test2) */ * from test2 where object id «1000; 


942 rows selected. 
Execution Plan 


Plan hash value: 3711990673 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| 
| 0 | SELECT STATEMENT | | 942 | 190K| 855 (0) | 
| 1 | TABLE ACCESS BY INDEX ROWID| TEST2 | 942 | 190K| 855 (0) | 
|% 2 | INDEX RANGE SCAN | IDX ID2 | 942 | | 4 (0) | 





现在 我 们 


00:00:11 | 
00200211 | 
00:00:01 | 


16 表 与 表 之 间 关 系 
2 - access("OBJECT ID"«1000) 


- dynamic sampling used for this statement (level-2) 


Statistics 


0 recursive calls 
0 db block gets 
943 consistent gets 
0 physical reads 
0 redo size 
86510 bytes sent via SQL*Net to client 
420 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
942 rows processed 


通过 上 面 实验 我 们 得 知 ， 集 群 因子 太 大 会 严重 影响 索引 回 表 的 性 能 。 

集群 因子 究竟 影响 的 是 什么 性 能 呢 ? 集群 因子 影响 的 是 索引 回 表 的 物理 IO 次 数 .我 们 假 
设 索 引 范 围 扫描 返回 了 1000 行 数据 ， 如 果 buffer cache 中 没有 缓存 表 的 数据 块 ， 假 设 这 1000 
行 数据 都 在 同一 个 数据 块 中 ， 那 么 回 表 需 要 耗费 的 物理 IO 就 只 需要 一 个 ; 假设 这 1000 行 数 
据 都 在 不 同 的 数据 块 中 ， 那 么 回 表 就 需要 耗费 1000 个 物理 TO。 因 此 ， 集 群 因子 影响 索引 回 
表 的 物理 IO 次 数 。 

请 注意 , 不 要 尝试 重建 索引 来 降低 集群 因子 , 这 根本 没 用 , 因为 表 中 的 数据 顺序 始终 没 变 。 
唯一 能 降低 集群 因子 的 办 法 就 是 根据 索引 列 排序 对 表 进 行 重建 (create table new. table as select 
* from old table order by 索引 列 )， 但 是 这 在 实际 操作 中 是 不 可 取 的 ， 因 为 我 们 无 法 照顾 到 每 
全 | 个 

怎么 才能 避免 集群 因子 对 SQL 查询 性 能 产生 影响 呢 ? 其 实 前 文 已 经 有 了 答案 ， 集 群 因子 
只 影响 索引 范围 扫描 和 索引 全 扫描 。 当 索引 范围 扫描 , 索引 全 扫描 不 回 表 或 者 返回 数据 量 很 少 
的 时 候 ， 不 管 集群 因子 多 大 ， 对 SQL 查询 性 能 几乎 没有 任何 影响 。 

再 次 强调 一 遍 ， 在 进行 SQL 优化 的 时 候 ， 往 往 会 建立 合适 的 组 合 索引 消除 回 表 ， 或 者 建 
立 组 合 索引 尽量 减少 回 表 次 数 。 

如 果 无 法 避免 回 表 ， 怎 么 做 才能 消除 回 表 对 SQL 查询 性 能 产生 影响 呢 ? 当 我 们 把 表 中 所 
有 的 数据 块 缓存 在 buffer cache 中 ,这 个 时 候 不 管 集群 因子 多 大 ， 对 SQL 查询 性 能 也 没有 多 大 
影响 ， 因 为 这 时 不 需要 物理 TO， 数 据 块 全 在 内 存 中 访问 速度 是 非常 快 的 。 

在 本 书 第 6 章 中 我 们 还 会 进一步 讨论 集群 因子 。 


关系 型 数据 库 中 ， 表 与 表 之 间 会 进行 关联 ， 在 进行 关联 的 时 候 ， 我 们 一 定 要 理 清楚 表 与 表 之 
间 的 关系 。 表 与 表 之 间 存 在 3 种 关系 。 一 种 是 1 : 1 关系 ， 一 种 是 1 : N 关系， 最 后 一 种 是 N : N 
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第 1 章 SQL 优化 必 懂 概念 XE 


AUR. 318225202 BIA. Р SQL 优化 、SQL 等 价 改写 、 表 设计 优化 以 及 分 表 分 库 都 有 
巨大 帮助 。 

两 表 在 进行 关联 的 时 候 ， 如 果 两 表 属 于 1 : 1 关系 ， 关 联 之 后 返回 的 结果 也 是 属于 1 的 关 
系 ， 数 据 不 会 重复 。 如 果 两 表 属 于 1 : NN 关系， 关联 之 后 返回 的 结果 集 属于 N 的 关系 。 如 果 两 
表 属 于 N: N 关系 ， 关 联 之 后 返回 的 结果 集会 产生 局 部 范围 的 笛 卡 儿 积 ，N : N 关系 一 般 不 存 
在 内 /外 连接 中 ， 只 能 存在 于 半 连 接 或 者 反 连 接 中 。 

如 果 我 们 不 知道 业务 ， 不 知道 数据 字典 ， 怎 么 判断 两 表 是 什么 关系 呢 ? 我 们 以 下 面 SQL 
为 例子 。 


| select * from emp e, dept d where e.deptno = d.deptno; 


我 们 只 需要 对 两 表 关 联 列 进行 汇总 统计 就 能 知道 两 表 是 什么 关系 。 
SOL» select deptno, count(*) from emp group by deptno order by 2 desc; 


DEPTNO COUNT (*) 


SOL» select deptno, count(*) from dept group by deptno order by 2 desc; 


DEPTNO COUNT (*) 


从 上 面 查询 我 们 可 以 知道 两 表 emp 与 dept №: 1 关系 。 搞 清楚 表 与 表 之 间 关 系 对 于 SQL 
优化 很 有 帮助 。 
2013 年 ， 我 们 曾 遇 到 一 个 案例 ，SQL 运行 了 12 秒 ，SQL 文本 如 下 。 


| select count(*) from а left join b оп a.id=b.id; 


案例 中 a 与 b 是 1 : 1 关系 ,，a 5 b 都 是 上 千 万 数据 量 。 因 为 a 与 b 是 使 用 外 连接 进行 关 
Ж, 不 管 a 与 b 是否 关 联 上 , 始终 都 会 返回 a 的 数据 , SQL 语句 中 求 的 是 两 表 关 联 后 的 总 行 数 ， 
因为 两 表 是 1 ; 1 关系 ， 关 联 之 后 数据 不 会 翻番 ， 那 么 该 SQL 等 价 于 如 下 文本 。 


| select count(*) from a; 


我 们 将 SQL 改写 之 后 , 查询 可 以 秒 出 。 如 果 a j b n: 1 关系 , 我 们 也 可 以 将 b 表 去 掉 ， 
因为 两 表 关 联 之 后 数据 不 会 翻 倍 。 如果 b 表 属于 n 的 关系 , 这 时 我 们 不 能 去 掉 b 表 ， 因 为 这 时 
关联 之 后 数据 量 会 翻番 。 

在 本 书后 面 的 标量 子 查 询 等 价 改写 、 半 连接 等 价 改写 以 及 SQL 优化 案例 章节 中 我 们 就 会 
用 到 表 与 表 之 间 关 系 这 个 重要 的 概念 。 


第 2 章 统计 信息 


前 面 提 到 ， 只 有 大 表 才 会 产生 性 能 问题 , 那么 怎么 才能 让 优化 器 知道 某 个 表 多 大 呢 ? 这 就 
需要 对 表 收 集 统计 信息 。 我们 在 第 一 章 提 到 的 基数 、 直 方 图 、 集群 因子 等 概念 都 需要 事先 收集 
统计 信息 才能 得 到 。 

统计 信息 类 似 于 战争 中 的 侦察 兵 ， 如 果 情 报 工作 没有 做 好 ， 打 仗 就 会 输 掉 战 争 。 同 样 的 道 
理 ， 如 果 没 有 正确 地 收集 表 的 统计 信息 ， 或 者 没有 及 时 地 更 新 表 的 统计 信息 ，SQL 的 执行 计 
划 就 会 跑 偏 ，SQL 也 就 会 出 现 性 能 问题 。 收 集 统计 信息 是 为 了 让 优化 器 选择 最 佳 执行 计划 ， 
以 最 少 的 代价 (成 本 ) 查询 出 表 中 的 数据 。 

统计 信息 主要 分 为 表 的 统计 信息 、 列 的 统计 信息 、 索 引 的 统计 信息 、 系 统 的 统计 信息 、 数 
据 字典 的 统计 信息 以 及 动态 性 能 视图 基 表 的 统计 信息 。 

关于 系统 的 统计 信息 、 数 据 字 典 的 统计 信息 以 及 动态 性 能 视图 基 表 的 统计 信息 本 书 不 做 讨 
论 ， 本 书 重 点 讨论 表 的 统计 信息 、 列 的 统计 信息 以 及 索引 的 统计 信息 。 

表 的 统计 信息 主要 包含 表 的 总 行 数 (num. rows)、 表 的 块 数 (blocks) 以 及 行 平 均 长 度 
(аур row_len)， 我 们 可 以 通过 和 查询 数据 字典 РВА TABLES 获取 表 的 统计 信息 。 

现在 我 们 创建 一 个 测试 表 T_STATS 。 


SQL» create table t stats as select * from dba objects; 





Table created. 


我 们 查看 表 T_STATS 常用 的 表 的 统计 信息 。- 


SQL» select owner, table name, num rows, blocks, avg row len 
2 from dba tables 


3 where owner = 'SCOTT' 

4 and table name - 'T STATS'; 
OWNER TABLE NAME NUM ROWS BLOCKS AVG ROW LEN 
SCOTT T STATS 


因为 T_ STATS 是 新 创建 的 表 ， 没 有 收集 过 统计 信息 ， 所 以 从 DBA TABLES 查询 数据 是 
的 。 
现在 我 们 来 收集 表 T_STATS 的 统计 信息 。 


Hr 


SQL> BEGIN 
z DBMS STATS.GATHER TABLE STATS (ownname => 'SOOTT!', 
3 tabname =>» UPSTATS!, 


4 estimate percent => 100, 


第 2 章 统计 信息 





5 method_opt => 'for all columns size auto", 
6 no invalidate -» FALSE, 

7 degree => 1, 

8 cascade => TRUE); 

9 END; 
105 7 


PL/SQL procedure successfully completed. 


我 们 再 次 查看 表 的 统计 信息 。 


SQL» select owner, table name, num rows, blocks, avg row len 


2 from dba tables 
3 where owner - 'SCOTT' 
4 and table name - 'T STATS'; 
OWNER TABLE NAME NUM ROWS BLOCKS AVG ROW LEN 
SCOTT T STATS 72674 1061 ү ЕТ 
从 查询 中 我 们 可 以 看 到 ， 表 T_STATS 一 共有 72674 行 数据 ，1 061 个 数据 块 ， 平 均 行 长 
REX 97 字 节 。 


列 的 统计 信息 主要 包含 列 的 基数 、 列 中 的 空 值 数量 以 及 列 的 数据 分 布 情况 (直方 图 )。 我 
们 可 以 通过 数据 字典 DBA TAB COL STATISTICS 查看 列 的 统计 信息 。 
现在 我 们 查看 表 T STATS 常用 的 列 统计 信息 。 


SQL> select column name, num distinct, num nulls, num buckets, histogram 


2 from dba tab col statistics 

3 where owner = 'SCOTT' 

4 and table name = "Т STATS"; 
COLUMN NAME NUM DISTINCT NUM NULLS NUM BUCKETS HISTOGRAM 
EDITION NAME 0 72674 0 NONE 
NAMESPACE 21 i! 1 NONE 
SECONDARY @ 0 1 NONE 
GENERATED 2 0 1 NONE 
TEMPORARY 2 0 1 NONE 
STATUS 2 0 1 NONE 
TIMESTAMP 1592 1 1 NONE 
LAST DDL TIME 1521 1 1 NONE 
CREATED 1472 0 1 NONE 
OBJECT TYPE 45 0 1 NONE 
DATA OBJECT ID 7796 64833 1 NONE 
OBJECT_ID 72673 1 1 NONE 
SUBOBJECT NAME 140 72145 1 NONE 
OBJECT NAME 44333 0 1 NONE 
OWNER 3d 0 1 NONE 


15 rows selected. 


上 面 查询 中 ， 第 一 个 列表 示 列 名 字 ， 第 二 个 列表 示 列 的 基数 ， 第 三 个 列表 示 列 中 NULL 
值 的 数量 ， 第 四 个 列表 示 直 方 图 的 桶 数 ， 最 后 一 个 列表 示 直 方 图 类 型 。 
在 工作 中 ， 我 们 经 常 使 用 下 面 脚本 查看 表 和 列 的 统计 信息 。 


SQL» select a.column name, 
2 b.num rows, 
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3 a.num_nulls, 

4 a.num_distinct Cardinality, 

5 round(a.num distinct / b.num rows * 100, 2) selectivity, 
6 a.histogram, к 

1 a.num_buckets 

8 from dba tab col statistics a, dba tables b 

9 where a.owner - b.owner 

10 and a.table name - b.table name 

11 
12 


and a.owner = 'SCOTT' 

and a.table name - 'T STATS'; 
COLUMN NAME NUM ROWS МОМ NULLS CARDINALITY SELECTIVITY HISTOGRAM NUM BUCKETS 
EDITION NAME 72674 72674 0 0 NONE 0 
NAMESPACE 72674 1 21 .03 МОМЕ 1 
SECONDARY 72674 0 2 0 NONE | 
GENERATED 72674 0 2 0 NONE 1 
TEMPORARY 72674 0 2 0 NONE X 
STATUS 72674 0 2 0 МОМЕ 1| 
TIMESTAMP 72674 1 1592 2.19 NONE 1 
LAST DDL TIME 72674 1 1521 2.09 NONE 1 
CREATED 72674 0 1472 2.03 NONE 1 
OBJECT TYPE 72674 0 45 .06 NONE 1 
DATA OBJECT ID 72674 64833 7796 10.73 NONE 1 
OBJECT_ID 72674 1 72673 100 NONE 1 
SUBOBJECT_NAME 72674 72145 140 .19 NONE 1 
OBJECT NAME 72674 0 44333 61 NONE 1 
OWNER 72674 0 31 .04 NONE 1 


15 rows selected. 


索引 的 统计 信息 主要 包含 索引 blevel (索引 高 度 -1)、 叶 子 块 的 个 数 《〈leaf_ blocks) 以 及 集 
群 因子 (clustering_factor)。 我 们 可 以 通过 数据 字典 DBA_INDEXES 查看 索引 的 统计 信息 。 
我 们 在 OBJECT_ID 列 上 创建 一 个 索引 。 


SQL» create index idx t stats id on t stats(object id); 


Index created. 


创建 索引 的 时 候 会 自动 收集 索引 的 统计 信息 ， 运 行 下 面 脚 本 查看 索引 的 统计 信息 。 


SQL» select blevel, leaf blocks, clustering factor,status 


2 from dba indexes 
3 where owner = 'SCOTT' 
4 and index name - 'IDX T STATS ID'; 


BLEVEL LEAF BLOCKS CLUSTERING FACTOR STATUS 


1 161 1127 VALID 
如 果 要 单独 对 索引 收集 统计 信息 ， 可 以 使 用 下 面 脚本 收集 。 
SQL» BEGIN 


2 DBMS STATS.GATHER INDEX STATS(ownname -» 'SCOTT', 
3 indname => 'IDX T STATS ID'); 
4 END; 

SA У 


PL/SQL procedure successfully completed. 
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在 本 书 第 6 章 中 , 我 们 会 详细 介绍 表 的 统计 信息 、 列 的 统计 信息 以 及 索引 的 统计 信息 是 如 
何 被 应 用 于 成 本 计算 的 。 
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我 们 通常 使 用 下 面 脚本 收集 表 和 索引 的 统计 信息 。 







BEGIN 
DBMS STATS.GATHER TABLE STATS (ownname -» 'TAB OWNER', 

tabname => 'TAB NAME', 
estimate percent => 根据 表 大 小 设置 ， 
method opt => 'for all columns size repeat', 
no_invalidate => FALSE, 
degree => 根据 表 大 小 ，CPU 资源 和 负载 设置 ， 
granularity => 'AUTO', 
сазсаае => TRUE); 

END; 

/ 


ownname 表示 表 的 拥有 者 ， 不 区 分 大 小 写 。 

tabname 表示 表 名 字 ， 不 区 分 大 小 写 。 

granularity 表示 收集 统计 信息 的 粒度 ， 该 选项 只 对 分 区 表 生 效 ， 默 认为 AUTO， 表 示 让 
Oracle 根据 表 的 分 区 类 型 自己 判断 如 何 收集 分 区 表 的 统计 信息 。 对 于 该 选项 ， 我 们 一 般 采 用 
AUTO 方式 ， 也 就 是 数据 库 默 认 方式 ， 因 此 ， 在 后 面 的 脚本 中 ， 省 略 该 选项 。 

estimate percent 表示 采样 率 ， 范 围 是 0.000 001 一 100。 

我 们 一 般 对 小 于 1GB 的 表 进 行 100% 采 样 ， 因 为 表 很 小 ， 即 使 100% 采 样 速度 也 比较 快 。 
有 时 候 小 表 有 可 能 数据 分 布 不 均衡 ， 如 果 没 有 100% 采 样 ， 可 能 会 导致 统计 信息 不 准 。 因 此 我 
们 建议 对 小 表 100% 采 样 。 

我 们 一 般 对 表 大 小 在 1GB—5GB 的 表 采 样 50%， 对 大 于 5GB 的 表 采 样 30%。 如 果 表 特别 
大 ， 有 几 十 甚至 上 百 GB, 我 们 建议 应 该 先 对 表 进 行 分 区 , 然后 分 别 对 每 个 分 区 收集 统计 信息 。 

一 般 情况 下 ， 为 了 确保 统计 信息 比较 准确 ， 我 们 建议 采样 率 不 要 低 于 30%。 

我 们 可 以 使 用 下 面 脚本 查看 表 的 采样 率 。 


SQL> SELECT owner, 


2 table name, 

3 num rows, 

4 sample size, 

5 round(sample size / num rows * 100) estimate percent 

6 FROM DBA TAB STATISTICS 

7 WHERE owner-'SCOTT' AND table name-'T STATS'; 
OWNER TABLE NAME NUM ROWS SAMPLE SIZE ESTIMATE PERCENT 
SCOTT T STATS 72674 72674 100 


从 上 面 查询 我 们 可 以 看 到 ,对 表 T_STATS 是 100% 采 样 的 。 现 在 我 们 将 采样 率 设置 为 30%。 


SQL> BEGIN 
2 DBMS STATS.GATHER TABLE STATS (ownname => "SCOTT", 


22 统计 信息 重要 参数 设置 


3 tabname => 'T STATS', 

4 estimate percent => 30, 

5 method opt -» 'for.all columns size auto', 
6 no invalidate -» FALSE, 

W degree => 1; 

8 cascade => TRUE); 

9 END; 

qg 4 


PL/SQL procedure successfully completed. 


SQL> SELECT owner, 


2 table name, 

3 num rows, 

4 sample_size, 

5 round(sample size / num rows * 100) estimate percent 

6 FROM DBA TAB STATISTICS 

7 WHERE owner-'SCOTT' AND table name-'T STATS'; 
OWNER TABLE NAME NUM ROWS SAMPLE SIZE ESTIMATE PERCENT 
SCOTT T STATS 73067 21920 30 


从 上 面 查询 我 们 可 以 看 到 采样 率 为 30%， 表 的 总 行 数 被 估算 为 73 067， 而 实际 上 表 的 总 


行 数 为 72 674。 设 置 采 样 率 30% 的 时 候 ， 一 共 分 析 了 21920 条 数据 ， 表 的 总 行 数 等 于 
round(21 920*100/30)， 也 就 是 73 067。 


除非 一 个 表 是 小 表 ， 和 否则 没有 必要 对 一 个 表 100% 采 样 。 因 为 表 一 直 都 会 进行 DML 操作 ， 


表 中 的 数据 始终 是 变化 的 。 


method_opt 用 于 控制 收集 直方 图 策略 。 
method opt => 'for all columns size 1' 表示 所 有 列 都 不 收集 直方 图 ， 如 下 


所 示 。 


SQL> BEGIN 
2 DBMS STATS.GATHER TABLE STATS (ownname => '"SCOTT', 
3 tabname => UD STATS”, 
4 estimate percent => 100, 
5 method opt => "for all columns size 1", 
6 no invalidate -» FALSE, 
7 degree => 1, 
8 cascade => TRUE); 
9 END; 
10 / 


PL/SQL procedure successfully completed. 


我 们 查看 直方 图 信息 。 


SQL» select a.column name, 


2 b.num rows, 

d a.num nulls, 

4 a.num distinct Cardinality, 

5 round(a.num distinct / b.num rows * 100, 2) selectivity, 
6 a.histogram, 

7 a.num buckets 

8 from dba tab col_statistics a, dba tables b 

9 where a.owner = b.owner 
10 and a.table name = b.table name 
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11 and a.owner = 'SCOTT' 

12 and a.table name = 'T STATS'; 
COLUMN NAME NUM ROWS NUM NULLS CARDINALITY SELECTIVITY HISTOGRAM NUM ВОСКЕТ5 
EDITION NAME 72674 72674 0 0 МОМЕ 0 
NAMESPACE 72674 1 22 .03 МОМЕ 1 
SECONDARY 72674 0 2 0 NONE 1 
GENERATED 72674 0 2 0 NONE 1 
TEMPORARY 72674 0 2 0 NONE £ 
STATUS 72674 0 2 0 NONE 1 
TIMESTAMP 72674 1 1592 2.19 NONE 1 
LAST DDL TIME 72674 x 1521 2.09 NONE 1 
CREATED 72674 0 1472 2.03 NONE 1 
OBJECT TYPE 72674 0 45 .06 NONE 1 
DATA OBJECT ID 72674 64833 7796 10.73 МОМЕ b 
OBJECT ID 72614 1 72673 100 МОМЕ 1 
SUBOBJECT NAME 72674 72145 140 .19 NONE 1 
OBJECT NAME 72614 0 44333 61 NONE 1 
OWNER 72674 0 3X .04 NONE 1 


15 rows selected. 


从 上 面 查询 我 们 看 到 ， 所 有 列 都 没有 收集 直方 图 。 
method opt => 'for all columns size skewonly' 表示 对 表 中 所 有 列 收集 自 
动 判断 是 否 收集 直方 图 ， 如 下 所 示 。 


SQL» BEGIN 
2 DBMS STATS.GATHER TABLE STATS (ownname => 'SCOTT', 
3 tabname => "Т STATS', 
4 estimate_percent => 100, 
5 method opt => 'for all columns size skewonly', 
6 no invalidate -» FALSE, 
7 degree -> 1, 
8 сазсаде => TRUE); 
9 END; 
10 / 


PL/SQL procedure successfully completed. 


我 们 查看 直方 图 信息 ， 如 下 所 示 。 


SQL> select a.column name, 
2 b.num rows, 
3 a.num nulls, 
4 a.num distinct Cardinality, 
5 round(a.num distinct / b.num rows * 100, 2) selectivity, 
6 a.histogram, 
7 a.num buckets 
8 from dba tab col statistics a, dba tables b 
9 where a.owner - b.owner 


10 and a.table name - b.table name 

11 and a.owner = 'SCOTT' 

12 and a.table name - 'T STATS'; 
COLUMN NAME NUM .ROWS МОМ NULLS CARDINALITY SELECTIVITY HISTOGRAM МОМ BUCKETS 
EDITION NAME 72674 72674 0 0 МОМЕ 0 
NAMESPACE 72674 Т 21 .03 FREQUENCY 21 
SECONDARY 72674 0 2 0 FREQUENCY 2 


22 ”统计 信息 重要 参数 设置 


GENERATED 72674 0 2 0 FREQUENCY 2 
TEMPORARY 72674 0 2 0 FREQUENCY 2 
STATUS 72674 0 2 0, FREQUENCY 2 
TIMESTAMP 72674 1 1592 2.19 HEIGHT BALANCED 254 
LAST DDL TIME 72674 2 1521 2.09 HEIGHT BALANCED 254 
CREATED 72674 0 1472 2.03 HEIGHT BALANCED 254 
OBJECT TYPE 72674 0 45 .06 FREQUENCY 45 
DATA OBJECT ID 12674 64833 7196 10.73 HEIGHT BALANCED 254 
OBJECT ID 72674 Z: 72673 100 NONE i 
SUBOBJECT NAME 72674 72145 140 119 FREQUENCY 140 
OBJECT МАМЕ ; 72674 0 44333 61 HEIGHT BALANCED 254 
OWNER 72674 0 31 .04 FREQUENCY 33 


15 rows selected. 


从 上 面 查询 我 们 可 以 看 到 ， 除 了 OBJECT ID ЖЖП EDITION NAME 列 ， 其 余 所 有 列 都 收 
集 了 直方 图 。 因 为 EDITION NAME 列 全 是 NULL， 所 以 没 必要 收集 直方 图 。OBJECT ID 列 
选择 性 为 100%， 没 必要 收集 直方 图 。 

在 实际 工作 中 千 万 不 要 使 用 method opt => 'for all columns size skewonly' 
收集 直方 图 信息 ， 因 为 并 不 是 表 中 所 有 的 列 都 会 出 现在 where 条 件 中 ,对 没有 出 现在 where 条 
件 中 的 列 收集 直方 图 没有 意义 。 

method opt => 'for all columns size auto' 表示 对 出 现在 where 条 件 中 的 列 
自动 判断 是 否 收集 直方 图 。 

现在 我 们 删除 表 中 所 有 列 的 直方 图 。 


SQL> BEGIN 
2 DBMS STATS.GATHER TABLE STATS (ownname => VSCOTT', 
3 tabname => "Т STATS', 
4 estimate percent => 100, 
5 method opt => 'for all columns size 1", 
6 no invalidate => FALSE, 
7 degree => 1, 
8 cascade => TRUE); 
9 END; 
SU 7; 


PL/SQL procedure successfully completed. 


我 们 执行 下 面 SQL， 以 便 将 owner 列 放 入 where 条 件 中 。 
SOL» select count(*) from t stats where owner-'SYS'; 


COUNT (*) 


接 下 来 我 们 刷新 数据 库 监 控 信 息 。 
SQL> begin 
2 dbms stats.flush database monitoring info; 


3 end; 
4' / 


PL/SQL procedure successfully completed. 


我 们 使 用 method opt => 'for all columns size auto' 方 式 对 表 收 集 统计 信息 。 
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SQL> BEGIN 
2 DBMS STATS.GATHER TABLE STATS (ownname => 'SCOTT', 
3 tabname => 'T STATS', 
4 estimate percent => 100, 
5 method opt => 'for all columns size auto', 
6 no invalidate => FALSE, 
Z! degree => 1, 
8 cascade => TRUE); 
9 END; 
i0; ХА 


PL/SQL procedure successfully completed. 


然后 我 们 查看 直方 图 信息 。 


SQL» select a.column name, 
2 b.num rows, 


3 a.num nulls, 

4 a.num distinct Cardinality, 

5 round(a.num distinct / b.num rows * 100, 2) selectivity, 

6 a.histogram, 

1 a.num buckets 

8 from dba tab col statistics a, dba tables b 

9 where a.owner = b.owner 

10 and a.table name - b.table name 

11 and a.owner = 'SCOTT' 

12 and a.table name - 'T STATS'; 
COLUMN NAME NUM ROWS NUM NULLS CARDINALITY SELECTIVITY HISTOGRAM NUM BUCKETS 
EDITION NAME 72674 72674 0 0 МОМЕ 0 
NAMESPACE 72674 1 21 .03 NONE 1 
SECONDARY 72674 0 2 0 NONE 1 
GENERATED 72674 0 2 0 NONE 1 
TEMPORARY 72674 0 92 0 NONE 1 
STATUS 72674 0 2 0 NONE 1 
TIMESTAMP 72674 Ln 1592 2.19 NONE 1 
LAST DDL TIME 72674 1 1521 2.09 NONE 1 
CREATED 72674 0 1472 2.03 NONE 1 
OBJECT TYPE 72614 0 45 06 NONE 1 
DATA OBJECT ID 72674 64833 7796 10.73 NONE 1 
OBJECT ID 72674 1 72673 100 МОМЕ 1 
SUBOBJECT NAME 72614 72145 140 .19 NONE 1 
OBJECT NAME 72674 0 44333 61 NONE i 
OWNER 72674 0 31 .04 FREQUENCY 31 


15 rows selected. 


从 上 面 查询 我 们 可 以 看 到 ，Oracle 自动 地 对 owner 列 收集 了 直方 图 。 
思考 ， 如 果 将 选择 性 比较 高 的 列 放 入 where 条 件 中 , 会 不 会 自动 收集 直方 图 ? 现在 我 们 将 
OBJECT NAME 列 放 入 where 条 件 中 。 


SQL» select count(*) from t stats where object name-'EMP'; 


COUNT (*) 


然后 我 们 刷新 数据 库 监控 信息 。 


22 ”统计 信息 重要 参数 设置 


SQL> begin 
2 dbms stats.flush database monitoring info; 
3 end; 
4 / 


PL/SQL procedure successfully completed. 


我 们 收集 统计 信息 。 
SQL> BEGIN 
2 DBMS STATS.GATHER TABLE STATS (ownname -» 'SCOTT', 
3 tabname => "T STATS', 
4 estimate percent => 100, 
5 method opt -» 'for all columns size auto', 
6 no invalidate => FALSE, 
7 degree => 1, 
8 cascade => TRUE); 
9 END; 
10 / 


PL/SQL procedure successfully completed. 


我 们 查看 OBJECT NAME 列 是 否 收 集 了 直方 图 。 


SQL> select a.column name, 
2 b.num rows, 
3 a.num nulls, 
4 a.num distinct Cardinality, 
5 round(a.num distinct / b.num rows * 100, 2) selectivity, 
6 a.histogram, 
у! a.num buckets 
8 from dba tab col statistics a, dba tables b 
9 where a.owner = b.owner 


10 and a.table name = b.table name 

do and a.owner = 'SCOTT' 

12 and a.table name = 'T STATS'; 
COLUMN NAME NUM ROWS МОМ NULLS CARDINALITY SELECTIVITY HISTOGRAM NUM ВОСКЕТ5 
EDITION NAME 72674 72614 0 0 NONE 0 
NAMESPACE 72674 1 21 .03 NONE 1 
SECONDARY 72674 0 2 0 NONE 1 
GENERATED 72674 0 2 0 NONE L 
TEMPORARY 72674 0 2 0 NONE 1 
STATUS 72674 0 2 0 NONE 1 
TIMESTAMP 4 72674 1 1592 2.19 МОМЕ 1 
LAST DDL TIME 72674 1 1521 2.09 NONE 1 
CREATED 72674 0 1472 2.03 NONE 1 
OBJECT TYPE 72674 0 45 .06 NONE 1 
DATA OBJECT ID 72674 64833 7796 10.73 МОМЕ 1 
OBJECT ID 72614 1 72673 100 NONE 1 
SUBOBJECT МАМЕ 72674 72145 140 .19 NONE 1 
OBJECT NAME 72674 0 44333 61 NONE £ 
OWNER 72674 0 31 .04 FREQUENCY Sub 


15 rows selected. 


从 上 面 查询 我 们 可 以 看 到 ，OBJECT NAME 列 没有 收集 直方 图 。 由 此 可 见 ， 使 用 AUTO 
方式 收集 直方 图 很 智能 。mothod opt 默认 的 参数 就 是 for all columns size auto. 
method opt => 'for all columns size repeat' 表示 当前 有 哪些 列 收集 了 直 
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方 图 ， 现 在 就 对 哪些 列 收集 直方 图 。 
当前 只 对 OWNER 列 收集 了 直方 图 ， 现 在 我 们 使 用 REPEAT 方式 收集 直方 图 。 


SQL> BEGIN 

2 DBMS STATS.GATHER TABLE STATS (ownname -» 'SCOTT', 

3 tabname => 'T STATS', 

4 estimate percent => 100, 

5 method opt -» 'for all columns size repeat 
' 

, 

6 по invalidate => FALSE, 

yi degree => 1, 

8 cascade => TRUE); 

9 END; 

10 / 


PL/SQL procedure successfully completed. 


我 们 查看 直方 图 信息 。 


SQL» select a.column name, 

2 b.num rows, 

3 a.num nulls, 

4 a.num distinct Cardinality, 

5 round(a.num distinct / b.num rows * 100, 2) selectivity, 
6 a.histogram, 

a.num buckets 

8 from dba tab col statistics a, dba tables b 
9 

10 

11 

12 


where a.owner = b.owner 

and a.table name = b.table name 

and a.owner - 'SCOTT' 

and a.table name - 'T STATS'; 
COLUMN NAME NUM ROWS МОМ NULLS CARDINALITY SELECTIVITY HISTOGRAM NUM BUCKETS 
EDITION NAME 72674 72674 0 0 МОМЕ 0 
NAMESPACE 72674 J. 21 .03 NONE 1 
SECONDARY 72674 0 2 0 NONE 1 
GENERATED 72674 0 2 0 NONE 1 
TEMPORARY 72674 0 2 0 NONE 1 
STATUS 72674 0 2 0 NONE 1 
TIMESTAMP 72674 1 1592 2.19 NONE 1 
LAST DDL TIME 726714 1 1521 2.09 NONE а 
CREATED 72674 0 1472 2.03 NONE 1 
OBJECT ТҮРЕ 72674 0 45 .06 NONE 1 
DATA OBJECT ID 72674 64833 7796 10.73 NONE 1 
OBJECT ID 72674 1 72673 100 NONE d 
SUBOBJECT NAME 72674 72145 140 .19 NONE 1 
OBJECT NAME 72674 0 44333 61 NONE 1 
OWNER 72674 0 ЗЕ .04 FREQUENCY 31 


15 rows selected. 


从 查询 中 我 们 可 以 看 到 ， 使 用 REPEAT 方式 延续 了 上 次 收集 直方 图 的 策略 。 对 一 个 运行 
稳定 的 系统 ， 我 们 应 该 采用 REPEAT 方式 收集 直方 图 。 

method opt => 'for columns object type. size skewonly' 表示 单 独 对 
OBJECT TYPE 列 收集 直方 图 ”对 于 其 余 列 ， 如 果 之 前 收集 过 直方 图 ， 现 在 也 收集 直方 图 。 


SQL» BEGIN 
2 DBMS STATS.GATHER TABLE STATS (ownname => 'SCOTT', 


22 统计 信息 重要 参数 设置 


3 tabname => 'T STATS', 

4 estimate percent -» 100, 

5 method opt -» 'for columns object type size skewonly', 
6 no invalidate -» FALSE, 

7 degree => 1, 

8 cascade => TRUE); 

9 END; 
10 ',/ 


PL/SQL procedure successfully completed. 


我 们 查看 直方 图 信息 。 


SQL» select a.column name, 

2 b.num rows, 

3 a.num nulls, 

4 a.num distinct Cardinality, 

5 round(a.num distinct / b.num rows * 100, 2) selectivity, 
6 a.histogram, 

7 a.num buckets 

8 from dba tab col statistics a, dba tables b 
9 
10 
АЛ 
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where a.owner = b.owner 

and a.table_name = b.table_name 

and a.owner = 'SCOTT' 

and a.table name = 'T STATS'; 
COLUMN NAME NUM ROWS NUM NULLS CARDINALITY SELECTIVITY HISTOGRAM NUM BUCKETS 
EDITION NAME 72674 72674 0 0 NONE 0 
NAMESPACE 72674 T 21 .03 NONE 1 
SECONDARY 72674 0 2 0 МОМЕ 1 
GENERATED 72674 0 2 0 NONE d 
TEMPORARY 72674 0 2 0 МОМЕ 2 
STATUS 72674 0 2 0 NONE 1 
TIMESTAMP 72674 1 1592 2.19 NONE 1 
LAST DDL TIME 72674 1 1521 2.09 NONE 1 
CREATED 72674 0 1472 2.03 NONE 1 
OBJECT TYPE 72674 0 45 .06 FREQUENCY 45 
DATA OBJECT ID 72674 64833 7196 10.73 NONE 1 
OBJECT ID 72674 1 72673 100 NONE 1 
SUBOBJECT NAME 72674 72145 140 -19 NONE 1 
OBJECT NAME 72674 0 44333 61 NONE 1 
OWNER 72674 0 31 .04 FREQUENCY 31 


15 rows selected. 


从 查询 中 我 们 可 以 看 到 , OBJECT TYPE 列 收集 了 直方 图 ， 因 为 之 前 收集 过 owner 列 直方 
图 ， 现 在 也 跟着 收集 了 owner 列 的 直方 图 。 

在 实际 工作 中 , 我 们 需要 对 列 收集 直方 图 就 收集 直方 图 , 需要 删除 某 列 直方 图 就 删除 其 直 
方 图 ， 当 系统 趋 于 稳定 之 后 ， 使 用 REPEAT 方式 收集 直方 图 。 

no invalidate 表示 共享 池 中 涉及 到 该 表 的 游标 是 否 立 即 失效 ， 默 认 值 为 DBMS STATS. 
AUTO_INVALIDATE， 表 示 让 Oracle 自己 决定 是 否 立 即 失效 。 我 们 建议 将 no_invalidate 参数 
设置 为 FALSE， 立 即 失效 。 因 为 我 们 发 现 有 时 候 SQL 执行 缓慢 是 因为 统计 信息 过 期 导致 ， 重 
新 收集 了 统计 信息 之 后 执行 计划 还 是 没有 更 改 ， 原 因 就 在 于 没有 将 这 个 参数 设置 为 false, 

degree 表示 收集 统计 信息 的 并 行 度 ， 默 认为 NULL。 如 果 表 没有 设置 degree， 收 集 统计 信 
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息 的 时 候 后 就 不 开 并 行 ， 如 果 表 设置 了 degree， 收 集 统 计 信息 的 时 候 就 按照 表 的 degree 来 开 
并 行 。 可 以 查询 DBA_TABLES.degree 来 查看 表 的 degree， 一 般 情 况 下 ， 表 的 degree 都 为 1。 
我 们 建议 可 以 根据 当时 系统 的 负载 、 系 统 中 CPU 的 个 数 以 及 表 大 小 来 综合 判断 设置 并 行 度 。 
cascade 表示 在 收集 表 的 统计 信息 的 时 候 ， 是 否 级 联 收集 索引 的 统计 信息 ， 默 认 值 为 
DBMS STATS.AUTO CASCADE, ЖЕ Oracle 自己 判断 是 否 级 联 收集 索引 的 统计 信息 。 我 
们 一 般 将 其 设置 为 TRUE， 在 收集 表 的 统计 信息 的 时 候 ， 级 联 收集 索引 的 统计 信息 。 
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收集 完 表 的 统计 信息 之 后 ， 如 果 表 中 有 大 量 数据 发 生变 化 ， 这 时 表 的 统计 信息 就 过 期 了 ， 
我 们 需要 重新 收集 表 的 统计 信息 ， 如 果 不 重新 收集 ， 可 能 会 导致 执行 计划 走 偏 。 
以 T_STATS 为 例 ， 我 们 先 在 owner 列 上 创建 一 个 索引 。 


| SQL» create index idx t stats owner on t_stats(owner); 











Index created. 


我 们 收集 owner 列 的 直方 图 信息 。 


SQL> BEGIN 
2 DBMS STATS.GATHER TABLE STATS (ownname => -*SCOTT', 
3 tabname => 'T STATS', 
4 estimate percent -» 100, 
5 method opt -» 'for columns owner size skewonly', 
6 no invalidate -» FALSE, 
7 degree => 1, 
8 cascade -» TRUE); 
9 END; 
10 / 


PL/SQL procedure successfully completed. 


我 们 执行 下 面 SQL 并 且 碍 看 执行 计划 〈 为 了 方便 排版 ， 省 略 了 执行 计划 中 的 Time 列 )。 
SQL» select * from t stats where owner-'SCOTT'; 


122 rows selected. 


Execution Plan 


| Id |Орегабіоп | Name | Rows | Bytes | Cost (%СРО) | 
| 0 |SELECT STATEMENT | | 122 | 11834 | 5 (0) | 
| 1 | TABLE ACCESS BY INDEX ROWID| T STATS | 1227| 117834 5 (0) | 
1% 2 | INDEX RANGE SCAN | IDX T STATS OWNER | 122: | 1 (0)1 


2.3 ”检查 统计 信息 是 否 过 期 


2 - access("OWNER"-'SCOTT') 


Statistics 


0 recursive calls 
0 db block gets 
26 consistent gets 
0 physical reads 
0 redo size 
13440 bytes sent via SQL*Net to client 
508 bytes received via SQL*Net from client 
10 SOQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
122 rows processed 


SQL 的 过 滤 条 件 是 where owner='SCOTT'， 因 为 收集 了 owner 列 的 直方 图 统计 ， 优 化 
器 能 准确 地 估算 出 SQL 返回 122 行 数据 ， 该 SQL 走 的 是 索引 范围 扫描 ， 执 行 计划 是 正确 的 。 

现在 我 们 更 新 表 中 的 数据 ， 将 object id«-10000 的 owner 更 新 为 'SCOTT'。 

SQL» update t stats set owner='SCOTT' where object id«-10000; 

9709 rows updated. 

SQL» commit; 

Commit complete. 
我 们 再 次 执行 SQL 并 且 查 看 执行 计划 。 

SQL» select * from t stats where owner-'SCOTT'; 


9831 rows selected. 


Execution Plan 


Plan hash value: 3912915053 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| 
| 0 | SELECT STATEMENT | | 122 | 11834 | 5 (0)1 
| 1 | TABLE ACCESS BY INDEX ROWID| T STATS | 122 | 11834 | 5 (0) | 
|* 2 | INDEX RANGE SCAN | IDX T STATS OWNER | 122 | | 1. (ӨЛІ 


2 - access ("OWNER"-'SCOTT') 


Statistics 
0 recursive calls 
0 db block gets 
1502 consistent gets 
0 physical reads 
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3236 redo size 
1005607 bytes sent via SQL*Net to client 
7625 bytes received via SQL*Net from client 
657 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
9831 rows processed 


从 执行 计划 中 可 以 看 到 ，SQL 一 共 返 回 了 9831 行 数据 , 但 是 优化 器 评估 只 返回 122 17% 
据 ， 因 为 优化 器 评估 where owner='SCOTT!' 只 返回 122 行 数 据 ， 所 以 执行 计划 走 了 索引 ， 
但 是 实际 上 应 该 走 全 表 扫 描 。 

为 什么 优化 器 会 评估 where owner='SCOTT' 只 返回 122 行 数据 呢 ? 原因 在 于 表 中 有 大 
量 数据 发 生 了 变化 , 但 是 统计 信息 没有 得 到 及 时 更 新 ， 优 化 器 还 是 采用 的 老 的 (过 期 的 ) 统计 
信息 来 估算 返回 行 数 。 

我 们 可 以 使 用 下 面 方法 检查 表 统 计 信 息 是 否 过 期 ， 先 刷新 数据 库 监 控 信息 。 


SQL> begin 
2 dbms stats.flush database monitoring info; 
3 end; 
5” 7 


PL/SQL procedure successfully completed. 


v 2 ` 
然后 我 们 执行 下 面 查询 。 
SQL> select owner, table name , object type, stale stats, last analyzed 
2 from dba tab statistics 
3 where owner = 'SCOTT' 
4 and table name - 'T STATS'; 
OWNER TABLE NAME OBJECT TYPE LAST ANALYZED 









SCOTT T STATS TABLE 24-MAY-17 


STALE STATS 显示 为 YES 表示 表 的 统计 信息 过 期 了 。 如 果 STALE STATS 显示 为 NO, 
表示 表 的 统计 信息 没有 过 期 。 
我 们 可 以 通过 下 面 查询 找 出 统计 信息 过 期 的 原因 。 


SQL» select table owner, table name, inserts, updates, deletes, timestamp 





2 from all tab modifications 
3 where table owner - 'SCOTT' 
4 and table name = 'T STATS'; 
TABLE OWNER TABLE NAME INSERTS 
SCOTT T STATS 0 9709 0 24-MAY-17 


从 查询 结果 我 们 可 以 看 到 ， 从 上 一 次 收集 统计 信息 到 现在 ， 表 被 更 新 了 9 709 行 数据 ， 所 
以 表 的 统计 信息 过 期 了 。 
现在 我 们 重新 收集 表 的 统计 信息 。 


SQL> BEGIN 
2 DBMS STATS.GATHER TABLE STATS (ownname => 'SCOTT', 
3 tabname => "Т STATS), 


2.3 ”检查 统计 信息 是 否 过 期 


4 estimate percent => 100, 

5 method opt => 'for columns owner size skewonly', 
6 no invalidate => FALSE,, 

7 degree -> 1, 

8 cascade => TRUE); 

9 END; 

10 / 


PL/SQL procedure successfully completed. 

我 们 再 次 查看 SQL 的 执行 计划 。 
SQL» select * from t stats where owner-'SCOTT'; 
9831 rows selected. 


Execution Plan 


Plan hash value: 1525972472 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time | 
| 0 | SELECT STATEMENT | | 9831 | 931K| 187 (2y| 90209293 | 
|% `1 | TABLE ACCESS FULL| T STATS | 9831 | 931К| 187 (2) 1 00:00:03 


1 = filter("OWNER"-'SCOTT') 


Statistics 
0 recursive calls 
0 db block gets 
consistent gets 
0 physical reads 
0 redo size 


418062 bytes sent via SQL*Net to client 
7625 bytes received via SQL*Net from client 
657 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
9831 rows processed 


重新 收集 完 统计 信息 之 后 ， 优 化 器 估算 返回 9 831 行 数据 ， 这 次 SQL 没 走 索引 扫描 而 是 
走 的 全 表 扫 描 ，SQL 走 了 正确 的 执行 计划 。 

细心 的 读者 可 能 会 认为 走 索 引 扫 描 的 性 能 高 于 全 表 扫 描 ， 因 为 索引 扫描 逻辑 读 为 502, 
而 全 表 扫 描 逻 辑 读 为 1 690， 所 以 索引 扫描 性 能 高 。 其 实 这 是 不 对 的 ， 衡量 一 个 SQL 的 性 能 不 
E 只 看 逻辑 读 ， 还 要 结合 SQL 的 物理 UO 次 数 综合 判断 。 本 书 第 4 章 会 就 为 什么 这 里 全 表 扫 
描 性 能 比索 引 扫 描 性 能 更 高 给 出 详细 解释 。 

Oracle 是 怎么 判断 一 个 表 的 统计 信息 过 期 了 呢 ? 当 表 中 有 超过 10% 的 数据 发 生变 化 


(INSERT，UPDATE，DELETE)， 就 会 引起 统计 信息 过 期 。 
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现在 我 们 查看 表 一 共有 多 少 行 数据 。 
SQL» select count(*) from t stats; 


COUNT (*) 


删除 表 中 10% 的 数据 ， 然 后 我 们 查看 表 的 统计 信息 是 否 过 期 。 


SQL» delete t stats where rownum<=72674*0.1+1; 
7268 rows deleted. 
SOL» commit; 


我 们 刷新 数据 库 监 控 信 息 。 


SQL> begin 
2 dbms stats.flush database monitoring info; 
3 епа; 
4 y 


PL/SQL procedure successfully completed. 


我 们 检查 表 统计 信息 是 否 过 期 。 


SQL> select owner, table name, object_type, stale_stats, last_analyzed 


2 from dba tab statistics 

3 where owner - 'SCOTT' 

4 and table name = 'T STATS'; 
OWNER TABLE NAME OBJECT TYP STALE STATS LAST ANALYZED 
SCOTT T STATS TABLE YES 24-MAY-17 


STALE STATS 显示 为 YES， 说 明 表 的 统计 信息 过 期 了 。 
我 们 查看 统计 信息 过 期 原因 。 


SQL> select table owner, table name, inserts, updates, deletes, timestamp 
2 from all tab modifications 
3 where table owner = 'SCOTT' 
4 and table name - 'T STATS'; 


TABLE OWNE TABLE NAME INSERTS UPDATES DELETES TIMESTAMP 


SCOTT T STATS 0 0 7268 24-MAY-17 


从 上 面 查 询 我 们 可 以 看 到 表 被 删除 了 7 268 行 数据 ， 从 而 导致 表 的 统计 信息 过 期 。 

在 进行 SQL 优化 的 时 候 ， 我 们 需要 检查 表 的 统计 信息 是 否 过 期 ， 如 果 表 的 统计 信息 过 期 
了 ， 要 及 时 更 新 表 的 统计 信息 。 

数据 字典 all tab modifications 还 可 以 用 来 判断 哪些 表 需 要 定期 降低 高 水 位 ， 比 如 一 个 表 
经 常 进行 nsert、delete， 那 么 这 个 表 应 该 定期 降低 高 水 位 ， 这 个 表 的 索引 也 应 该 定期 重建 。 除 
此 之 外 , all tab modifications 还 可 以 用 来 判断 系统 中 哪些 表 是 业务 核心 表 、 表 的 数据 每 天 增长 
量 等 。 
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24 扩展 统计 信息 


如 果 一 个 SQL 有 七 八 个 表 关 联 或 者 有 视图 套 视 图 等 ， 怎 么 快速 检查 SQL 语句 中 所 有 的 表 
统计 信息 是 和 否 过 期 呢 ? "T 
现 有 如 下 SQL。 


| select * from emp e,dept d where e.deptno-d.deptno; 
我 们 可 以 先 用 explain plan for MS, ТЕ plan table 中 生成 SQL 的 执行 计划 。 
SQL> explain plan for select * from emp e,dept d where e.deptno=d.deptno; : 


Explained. 


然后 我 们 使 用 下 面 脚本 检查 SQL 语句 中 所 有 的 表 的 统计 信息 是 否 过 期 。 


SQL> select owner, table name, object type, stale stats, last analyzed 


2 from dba tab statistics 
3 where (owner, table name) in 
4 (select object owner, object name 
5 from plan table 
6 where object type like '$TABLES' 
7 union 
8 select table owner, table name 
9 from dba indexes 
10 where (owner, index name) in 
14 (select object owner, object name 
12 from plan table 
13 where object_type like '%INDEX%')); 
OWNER TABLE NAME OBJECT TYP STALE STATS LAST ANALYZED 
SCOTT DEPT TABLE NO 05-DEC-16 
SCOTT EMP TABLE YES 22-OCT-16 
最 后 我 们 可 以 使 用 下 面 脚本 检查 SQL 语句 中 表 统 计 信 息 的 过 期 原因 。 
select * 


from all_tab_modifications 
where (table owner, table name) in 
(select object owner, object name 
from plan table 
where object type like '$TABLES' 
union 
select table owner, table name 
from dba indexes 
where (owner, index name) in 
(select object owner, object name 
from plan table 
where object type like '$INDEX$')); 


当 where 条 件 中 有 多 个 谓词 过 滤 条 件 ， 但 是 这 些 谓词 过 滤 条 件 彼此 是 有 关系 的 而 不 是 
相互 独立 的 ， 这 时 我 们 可 能 需要 收集 扩展 统计 信息 以 便 优 化 器 能 够 估算 出 较为 准确 的 行 
(Rows), 

我 们 创建 一 个 表 Т. 
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SQL> create table t as 
2 select level аз id, level || 'а' as a, level || level || 'b' as b 
3 from dual 
4 connect by level < 100; 


Table created. 


ТЕТ rB, Am А 列 的 值 就 知道 B 列 的 值 ，A 和 B 这 样 的 列 就 叫 作 相关 列 。 
我 们 一 直 执 行 insert into t select * from t; 直到 了 T 表 中 有 3244032 行 数据 。 


我 们 对 工 表 收 集 统 计 信息 。 
SOL» BEGIN 
2 DBMS STATS.GATHER TABLE STATS (ownname => 'SCOTT', 
3 tabname wh А, 
4 estimate percent => 100, 
5 method opt => 'for all columns size skewonly', 
6 no invalidate -» FALSE, 
7 degree => 1, 
8 cascade => TRUE); 
9 END; 
10 Z 


PL/SQL procedure successfully completed. 


我 们 查看 工 表 的 统计 信息 。 


SQL» select a.column name, 
b.num rows, 
a.num distinct Cardinality, 
round(a.num distinct / b.num rows * 100, 2) selectivity, 
a.histogram, 
a.num buckets 
from dba tab col statistics a, dba tables b 
where a.owner - b.owner 
and a.table name = b.table name 
and a.owner - 'SCOTT' 
and a.table name - 'T'; 


= © о со ы суль ОМ 


кҥн 


COLUMN. NAME NUM ROWS CARDINALITY SELECTIVITY HISTOGRAM NUM BUCKETS 


ID 3244032 99 0 FREQUENCY 99 
A 3244032 99 0 FREQUENCY 99 
B 3244032 99 0 FREQUENCY 99 


我 们 创建 两 个 索引 。 
SQL» create index idxl on 七 (a) 
Index created. 
SOL» create index idx2 on t(a,b); 
Index created. 
现 有 如 下 SQL 及 其 执行 计划 。 
SQL» select * from t where a-'la' and b-'llb'; 


32768 rows selected. 
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24 扩展 统计 信息 


Execution Plan 


Plan hash value: 2303463401 


| Id | Operation | Name | BOWS | Bytes | Cost ($CPU)| Time 





| 0 | SELECT STATEMENT | | | *4303.-| 84 (Oy 00:00:02 | 
| 1 | TABLE ACCESS BY INDEX ROWID| Т | | 4303 | 84 (0) | 00:00:02 | 
142) 620 INDEX КАМСЕ 5САМ | IDX2 | 


| | 3 (0)] 00:00:01 | 


2 - access("A"-']la' AND "B"-']1b') 


Statistics 
0 recursive calls 
0 db block gets 
11854 | consistent gets 
78 physical reads 
0 redo size 
775996 bytes sent via SQL*Net to client 
24444 bytes received via SQL*Net from client 
2186 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
32768 rows processed 


优化 器 估算 返回 331 行 数据 ， 但 是 实际 上 返回 了 32 768 行 数据 。 为 什么 优化 器 估算 返回 
的 行 数 与 真实 返回 的 行 数 有 这 么 大 差异 呢 ? 这 是 因为 优化 器 不 知道 A 与 В 的 关系 ， 所 以 在 佑 


算 返 回 行 数 的 时 候 采用 的 是 总 行 数 *A 的 选择 性 *B 的 选择 性 。 


SQL» select round(1/99/99*3244032) from dual; 


round (1/99/99*3244032) 


因为 A 列 的 值 可 以 决定 В 列 的 值 ， 所 以 上 述 SQL 可 以 去 掉 B 列 的 过 滤 条 件 。 


SOL» select * from t where а='1а'; 
32768 rows selected. 


Execution Plan 


Plan hash value: 1601196873 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time 
| 0 | SELECT STATEMENT | | 32768 | 416К| 1775 (3) | 00:00:22 | 
|% 1 | TABLE ACCESS FULL| T | 32768 | 416K| 1775 (3)| 00:00:22 | 


1 = filter("A"-'1a") 
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0 recursive calls 
0 db block gets 
10118 consistent gets 
0 physical reads 
0 redo size 
441776 bytes sent via SQL*Net to client 
24444 bytes received via SQL*Net from client 
2186 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
32768 rows processed 


这 时 优化 器 能 正确 地 估算 返回 的 Rows。 如 果 不 想 改写 SQL， 怎 么 才能 让 优化 器 得 到 比较 
准确 的 Rows WE? 在 Oraclellg 之 前 可 以 使 用 动态 采样 〈 至 少 Level 4)。 


SQL» alter session set optimizer dynamic sampling-4; 
Session altered. 
SOL» select * from t where a-'la' and b='11b'; 


32768 rows selected. 


Execution Plan 


Plan hash value: 1601196873 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time 
| 0 | SELECT STATEMENT | | 33845 | 429K| 1778 (3).]-00:00:22 | 
|* 1 | TABLE ACCESS FULL| T | 33845 | 429K| 1778 (3) 1 00:00:22 


1 一 filter("A"-'1a' AND "B"-']lb') 


- dynamic sampling used for this statement (level-4) 


Statistics 
0 recursive calls 
0 db block gets 
consistent gets 
0 physical reads 
0 redo size 


441776 bytes sent via SQL*Net to client 
24444 bytes received via SQL*Net from client 
2186 SQL*Net roundtrips to/from client 


0 sorts (memory) 
0 sorts (disk) 
32768 rows processed 


24 扩展 统计 信息 


使 用 动态 采样 Level4 采样 之 后 ， 优 化 器 估算 返回 33 845 行 数据 ， 实 际 返 回 了 32 768 fr 
数据 ， 这 已 经 比较 精确 了 。 在 Oraclellg 以 后 ， 我 们 可 以 使 用 扩展 统计 信息 将 相关 的 列 组 合 
成 一 个 列 。 

SQL» SELECT DBMS STATS.CREATE EXTENDED STATS(USER, "Т", '(A, B)') FROM DUAL; 


DBMS STATS.CREATE EXTENDED STATS (USER, 'T', ' (А,В) ') 


SYS STUNAS$6DVXJXTPOSEHS6DTIROX 


现在 我 们 对 表 重 新 收集 统计 信息 。 


SQL> BEGIN 
2 DBMS STATS.GATHER TABLE STATS (ownname => 'SGOOTT', 
3 tabname m» UN, 
4 estimate percent -» 100, 
5 method opt => 'for columns SYS STUNA$6DVXJXTPO5EH56DTIROX size skewonly', 
6 no invalidate -» FALSE, 
7 degree => 1, 
8 cascade => TRUE); 
9 END; 
10 у 


PL/SQL procedure successfully completed. 


我 们 查看 工 表 的 统计 信息 。 


SQL> select a.column name, 
2 b.num_rows, 
3 a.num distinct Cardinality, 
1 round(a.num distinct / b.num rows * 100, 2) selectivity, 
3 a.histogram, 
6 a.num buckets 
7 from dba tab col statistics a, dba tables b 
8 where a.owner - b.owner 
9 
0 
g 


and a.table_name = b.table_name 

3, and a.owner = 'SCOTT' 

1 and a.table пате = "Т"; 
COLUMN NAME NUM ROWS CARDINALITY SELECTIVITY HISTOGRAM NUM BUCKETS 
ID 3244032 99 0 FREQUENCY 99 
A 3244032 99 0 FREQUENCY 99 
B 3244032 99 0 FREQUENCY 99 
SYS STUNAS6DVXJXTPOSEHS6DTIROX 3244032 99 0 FREQUENCY 99 


重新 收集 统计 信息 之 后 ， 扩 展 列 SYS STUNAS6DVXIJXTPOSEHS6DTIROX 也 收集 了 直 


我 们 再 次 执行 SQL。 
SQL» select * from t where а='1а' and b='11b'; 


32768 rows selected. 


Execution Plan 


Plan hash value: 1601196873 
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| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time 
| 0 | SELECT STATEMENT | | 32768 | 416K| 1778 (3)| 00200222 | 
|% 1 | TABLE ACCESS FULL| Т | 32768 | 416K| 1778 (3)| 00:00:22 | 


1 = filter("A"-s'1la' AND "В"='116') 


Statistics 


1 recursive calls 
0 db block gets 
10118 consistent gets 
0 physical reads 
0 redo size 
441776 bytes sent via SQL*Net to client 
24444 bytes received via SQL*Net from client 
2186 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
32768 rows processed 


收集 完 扩展 统计 信息 之 后 ， 优 化 器 就 能 估算 出 较为 准确 的 Rows。 

需要 注意 的 是 ， 扩 展 统计 信息 只 能 用 于 等 值 查询 ， 不 能 用 于 非 等 值 查询 。 

在 本 书 的 SQL 优化 案例 赏析 章节 中 ， 我 们 将 会 为 各 位 读者 分 享 一 个 经 典 的 扩展 统计 信息 
优化 案例 。 


如 果 一 个 表 从 来 没收 集 过 统计 信息 ， 默 认 情 况 下 Oracle 会 对 表 进 行动 态 采样 (Level=2) 
以 便 优化 器 估算 出 较为 准确 的 Rows， 动 态 采 样 的 最 终 目的 就 是 为 了 让 优化 器 能 够 评估 出 较为 
准确 的 Rows。 

现在 我 们 创建 一 个 测试 表 T_DYNA。 


| SQL> create table t_dyna as select * from dba_objects; 





Table created. 
我 们 执行 下 面 SQL 并 且 查 看 执行 计划 。 


SQL» select count(*) from t dyna; 


Execution Plan 


| Id | Operation | Name | Rows | Cost ($CPU)| Time 
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25 动态 采样 


0 | SELECT STATEMENT | | 187 (1) | 00:00:03 | 
| 1 | SORT AGGREGATE | | ne | 
2 1 TABLE ACCESS FULL| T DYNA | 6530 187 (1)| 00:00:03 


люк = 


- dynamic sampling used for this statement (level=2) 


因为 表 T_DYNA 是 才 创 建 的 新 表 ， 没 有 收集 过 统计 信息 ， 所 以 会 启用 动态 采样 。 执 行 计 
划 中 dynamic sampling used for this statement (level=2) 表 示 启 用 了 动态 采 
FÉ, level 表示 采样 级 别 ， 默 认 情况 下 采样 级 别 为 2。 

动态 采样 的 级 别 分 为 11 级 。 

level 0: 不 启用 动态 采样 。 

level 1: 当 表 《〈 非 分 区 表 ) 没有 收集 过 统计 信息 并 且 这 个 表 要 与 另外 的 表 进 行 关 联 〈 不 能 
是 单 表 访 问 )， 同 时 该 表 没 有 索引 ， 表 的 数据 块 必须 大 于 32 个 ， 满 足 这 些 条 件 的 时 候 ，Oracle 
会 随机 扫描 表 中 32 个 数据 块 ， 然 后 评估 返回 的 Rows。 

level 2: 对 没有 收集 过 统计 信息 的 表 启 用 动态 采样 ， 采 样 的 块 数 为 64 个 ， 如 果 表 的 块 数 
小 于 64 个 ， 表 有 多 少 个 块 就 会 采样 多 少 个 块 。 

level 3: 对 没有 收集 过 统计 信息 的 表 启 用 动态 采样 ， 采 样 的 块 数 为 64 个 。 如 果 表 已 经 收 
集 过 统计 信息 ， 但 是 优化 器 不 能 准确 地 估算 出 返回 的 Rows， 而 是 靠 猜 ， 比 如 WHERE 
SUBSTR (owner, 1,3), ， 这 时 会 随机 扫 摘 64 个 数据 块 进行 采样 。 

level 4: 对 没有 收集 过 统计 信息 的 表 启 用 动态 采样 ， 采 样 的 块 数 为 64 个 。 如 果 表 已 经 收 
集 过 统计 信息 ， 但 是 表 有 两 个 或 者 两 个 以 上 过 滤 条 件 (AND/OR)， 这 时 会 随机 扫描 64 个 数据 
块 进行 采样 ， 相 关 列 问题 就 必须 启用 至 少 level 4 进行 动态 采样 。level4 采样 包含 了 level 3 的 

level 5: 收集 满足 level 4 采样 条 件 的 数据 ， 采 样 的 块 数 为 128 个 。 

level 6: 收集 满足 level 4 采样 条 件 的 数据 ， 采 样 的 块 数 为 256 个 。 

level 7: 收集 满足 level 4 采样 条 件 的 数据 ， 采 样 的 块 数 为 512 个 。 

level 8: 收集 满足 level 4 采样 条 件 的 数据 ， 采 样 的 块 数 为 1 024 个 。 

level 9: 收集 满足 level 4 采样 条 件 的 数据 ， 采 样 的 块 数 为 086 个 。 

level 10: 收集 满足 level 4 采样 条 件 的 数据 ， 采 样 表 中 所 有 的 数据 块 。 

level 11: Oracle 自动 判断 如 何 采 样 ， 采 样 的 块 数 由 Oracle 自动 决定 。 

在 2.4 节 中 我 们 已 经 演示 过 动态 采样 level 4 的 用 途 ,现在 将 为 各 位 读者 演示 动态 采样 level 
3 的 用 途 。 

我 们 执行 下 面 SQL 并 且 查 看 执行 计划 。 

SQL» select * from t dyna where substr(owner,4,3)-'LIC'; 


27699 rows selected. 
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Plan hash value: 1744410282 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time 
| 0 | SELECT STATEMENT | | 23044 | 4658К| 190 (3)1 00:00:03 | 
|* 1 | TABLE ACCESS FULL| T DYNA | 23044 | 4658K| 190 (3) | :00:00:203 1 


Predicate Information (identified by operation id): 


- dynamic sampling used for this statement (1еуе1=2) 


因为 T DYNA 没有 收集 过 统计 信息 ， 启 用 了 动态 采样 ， 采 样 级 别 默认 为 level 2， 动态 采 
样 估算 的 Rows(23 044) 与 真实 的 Rows(27 699) 比 较 接近 。 
现在 我 们 对 表 T_DYNA 收集 统计 信息 。 


SOL» BEGIN 
2 DBMS STATS.GATHER TABLE STATS (ownname -» 'SCOTT', 
3 tabname => "T DYNA', 
4 estimate_percent => 100, 
5 method opt => 'for all columns size skewonly', 
6 no invalidate -» FALSE, 
7 degree -> 1, 
8 cascade => TRUE); 
9 ЕМІ; 
T0. 7 


PL/SQL procedure successfully completed. 
我 们 再 次 查看 执行 计划 。 
SQL» select * from t dyna where substr(owner,4,3)-'LIC'; 


27699 rows selected. 


Execution Plan 


Plan hash value: 1744410282 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time | 
| 0 | SELECT STATEMENT | | 728 | 70616 | 190 (3)| 00:00:03 | 
|* 1 | TABLE ACCESS FULL] T DYNA | 728 | 70616 | 190 (3) 1 00:00:03 | 


1 = filter(SUBSTR("OWNER",4,3)-'LIC') 


25 动态 采样 


对 表 T DYNA 收集 了 统计 信息 之 后 ， 因 为 统计 信息 中 没有 包含 substr(owner,4,3) 
的 统计 ， 所 以 优化 器 无 法 估算 出 较为 准确 的 Rows， 优 化 器 估算 返回 了 728 行 数据 ， 而 实际 上 
返回 了 27 699 行 数据 。 现 在 我 们 将 动态 采样 leve 设置 为 3。 
SQL> alter session set optimizer dynamic sampling=3; 
Session altered. 
我 们 执行 SQL 并 且 查 看 执行 计划 。 
SQL> select * from t dyna where substr(owner,4,3)-'LIC'; 


27699 rows selected. 


Execution Plan 


Plan hash value: 1744410282 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time 
| 0 | SELECT STATEMENT | | 28795 | 2727К| 191 (3) 1 00:00:03 | 
|* 1 | TABLE ACCESS FULL| T DYNA | 28795 | 2727K| 191 (3) | 00:00:03 | 


- dynamic sampling used for this statement (level-3) 


将 动态 采样 设置 为 level 3 之 后 ， 优 化 器 发 现 where 条 件 中 有 substr (owner, 4,3), Ж 
法 估算 出 准确 的 Rows， 因 此 对 SQL 启用 了 动态 采样 ， 动 态 采样 估算 返回 了 28 795 行 数据 ， 
接近 于 真实 的 行 数 27 699。 
除了 设置 参数 optimizer dynamic sampling 启用 动态 采样 外 ， 我 们 还 可 以 添加 HINT 启用 
动态 采样 。 
SQL> alter session set optimizer_dynamic_sampling=2; 
Session altered. 
SQL» select /*+ dynamic sampling(3) */ * from t_dyna where substr(owner,4,3)='LIC'; 


27699 rows selected. 


Execution Plan 


Plan hash value: 1744410282 
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第 2 章 统计 信息 
0 | SELECT STATEMENT | | 28795 | 2727K| 191  (3)| 00:00:03 | 
ҮІ 


TABLE ACCESS FULL| Т DYNA | 28795 | 2727К| 191 (3)1 09:00:03 | 


- dynamic sampling used for this statement (1еуе1-3) 


如 果 表 已 经 收集 过 统计 信息 并 且 优化 器 能 够 准确 地 估算 出 返回 的 Rows， 即 使 添加 了 动态 
采样 的 HINT 或 者 是 设置 了 动态 采样 的 参数 为 level 3， 也 不 会 启用 动态 采样 。 
SQL» select /*+ dynamic sampling(3) */ * from t dyna where owner-'SYS'; 


30928 rows selected. 


Execution Plan 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time 
| 0 | SELECT STATEMENT | | 30928 | 2929К| 188 (2) | 00:00:03 | 
|% 1 | TABLE ACCESS FULL| T DYNA | 30928 | 2929К| 188 (2) | 00:00:03 | 


1 - filter("OWNER"-'SYS') 


因为 表 T DYNA 收集 过 统计 信息 ， 优 化 器 能 够 直接 根据 统计 信息 估算 出 较为 准确 的 
Rows， 所 以 ， 即 使 添加 了 HINT: /*+ dynamic sampling(3) */， 也 没有 启用 动态 采样 。 

什么 时 候 需 要 启用 动态 采样 呢 ? 

当 系 统 中 有 全 局 临时 表 ， 就 需要 使 用 动态 采样 ， 因 为 全 局 临时 表 无 法 收集 统计 信息 ， 我 们 
建议 对 全 局 临时 表 至 少 启用 level 4 进行 采样 。 

当 执 行 计划 中 表 的 Rows 估算 有 严重 偏差 的 时 候 , 例如 相关 列 问题 , 或 者 两 表 关联 有 多 个 
连接 列 ， 关 联 之 后 Rows 算 少 ,或 者 是 where 过 滤 条 件 中 对 列 使 用 了 substr, instr, like, X 
或 者 是 where 过 滤 条 件 中 有 非 等 值 过 滤 ， 或 者 group by 之 后 导致 Rows 估算 错误 ， 此 时 我 们 
可 以 考虑 使 用 动态 采样 ， 同 样 ， 我 们 建议 动态 采样 至 少 设置 为 level 4。 

在 数据 仓库 系统 中 , 有 些 报表 SQL 是 采用 Obiee/SAP BO/Congnos 自动 生成 的 ， 此 类 SQL 
一 般 都 有 几 十 行 甚至 几 百 行 ，SQL 的 过 滤 条 件 一 般 也 比较 复杂 ， 有 大 量 的 AND 和 OR ЧЕ 
件 ， 同 时 也 可 能 有 大 量 的 -where 子 查 询 过 滤 条 件 ，SQL 最 终 返 回 的 数据 量 其 实 并 不 多 。 对 于 
此 类 SQL， 如 果 SQL 执行 缓慢 ， 有 可 能 是 因为 SQL 的 过 滤 条 件 太 复杂 ， 从 而 导致 优化 器 不 能 
估算 出 较为 准确 的 Rows 而 产生 了 错误 的 执行 计划 。 我 们 可 以 考虑 启用 动态 采样 level 6 观察 性 


26 ”定制 统计 信息 收集 策略 


能 是 否 有 所 改善 ， 我 们 曾 利用 该 方法 优化 了 大 量 的 报表 SQL. 
最 后 ， 需 要 注意 的 是 ,不 要 在 系统 级 更 改动 态 采样 级 别 ， 默 认为 .2 就 行 ， 如 果 某 个 表 需 要 
启用 动态 采样 ， 直 接 在 SQL 语句 中 添加 HINT 即 可 。 


优化 器 在 计算 执行 计划 的 成 本 时 依赖 于 统计 信息 ， 如 果 没 有 收集 统计 信息 ， 或 者 是 统计 信 
息 过 期 了 ， 那 么 优化 器 就 会 出 现 严 重 偏差 ， 从 而 导致 性 能 问题 。 因 此 要 确保 统计 信息 准确 性 。 
虽然 数据 库 自 带 有 JOB 每 天 晚上 会 定时 收集 数据 库 中 所 有 表 的 统计 信息 ， 但 是 如 果 数 据 库 特 
别 大 ， 自 带 的 JOB 无 法 完成 全 库 统计 信息 收集 。 一些 资深 的 ОВА 会 关闭 数据 库 自 带 的 统计 信 
息 收 集 JOB， 根 据 实际 情况 自己 定制 收集 统计 信息 策略 。 

下 面 脚本 用 于 收集 SCOTT 账户 下 统计 信息 过 期 了 或 者 是 从 没收 集 过 统计 信息 的 表 的 统计 
信息 ， 采 样 率 也 根据 表 的 段 大 小 做 出 了 相应 调整 。 


declare 
cursor stale table is 
select owner, 
segment_name, 
case 





when segment_size < 1 then 
100 

when segment_size >= 1 and segment_size <= 5 then 
50 

when segment_size > 5 then 
30 


end as percent, 
6 as degree 
from (select owner, 
segment_name, 
sum(bytes / 1024 / 1024 / 1024) segment_size 
from Шы SEGMENTS 
where © DPE 
and Ee ғ 
(select table name 
from DBA TAB STATISTICS 








where (last _analyzed "d null or stale stats = 'YES') 
and бййёк е”! 
group by owner, segment | — 
begin 
dbms stats.flush database monitoring info; 
for stale in stale table loop 
dbms stats.gather table stats (ownname => stale.owner, 
tabname -» stale.segment name, 
estimate percent => stale.percent, 
method opt => 'for all columns size repeat', 
degree => stale.degree, 
cascade => true); 
end loop; 
end; 
/ 


在 实际 工作 中 ， 我 们 可 以 根据 自身 数据 库 中 实际 情况 ， 对 以 上 脚本 进行 修改 。 


48 


全 局 临时 表 无 法 收集 统计 信息 ， 我 们 可 以 抓 出 系统 中 的 全 局 临时 表 , 抓 出 系统 中 使 用 到 全 
局 临时 表 的 SQL， 然 后 根据 实际 情况 ， 对 全 局 临时 表 进 行动 态 采 样 ， 或 者 是 人 工 对 全 局 临时 
表 设 置 统 计 信 息 (DBMS STATS.SET TABLE STATS). 

下 面 脚本 抓 出 系统 中 使 用 到 全 局 临时 表 的 SQL。 


select b.object owner, b.object name, a.temporary, sql text 
from dba tables a, v$sql plan b, v$sql c 
where a.owner - b.object owner 
and a.temporary - 'Y' 
and a.table name - b.object name 
and Ь.заї іа = c.sql id; 


第 3 章 ， 执 行 计划 


SQL 执行 缓慢 有 很 多 原因 ， 有 时 候 是 数据 库 本 身 原 因 ， 比 如 LATCH 争 用 ， 或 者 某 些 参数 
设置 不 合理 。 有 时 候 是 SQL 写法 有 问题 ， 有 时 候 是 缺乏 索引 ， 可 能 是 因为 统计 信息 过 期 或 者 
没收 集 直方 图 ， 也 可 能 是 优化 器 本 身 并 不 完善 或 者 优化 器 自身 BUG 而 导致 的 性 能 问题 ,还 有 
可 能 是 业务 原因 ， 比 如 要 访问 一 年 的 数据 ， 然 而 一 年 累计 有 数 亿 条 数据 ， 数 据 量 太 大 导致 SQL 
性 能 缓慢 。 

如 果 是 数据 库 自 身 原 因 导 致 SQL 缓慢 ， 我 们 需要 通过 分 析 等 竺 事件 ， 做 出 相应 处 理 。 本 
书 侧重 讨论 单纯 的 SQL 优化 ， 因 此 更 侧重 于 分 析 SQL 写法 ， 分 析 SQL 的 执行 计划 。 

SQL 调 优 就 是 通过 各 种 手段 和 方法 使 优化 器 选择 最 佳 执行 计划 ， 以 最 小 的 资源 消耗 获取 
到 想 要 的 数据 。 
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3.1.1 使 用 AUTOTRACE 查看 执行 计划 
我 们 利用 SQLPLUS 中 自 带 的 AUTOTRACE 工具 查看 执行 计划 .AUTOTRACE 用 法 如 下 。 


SQL> set autot 
Usage: SET AUTOT[RACE] (OFF | ON | TRACE[ONLY]) [EXP[LAIN]] [STAT[ISTICS]] 


АЛЕТ A EE 


TW 4 т у 





方 插 号 内 的 字符 可 以 省 略 。 
set autoton: 该 命令 会 运行 SQL 并 且 显 示 运 行 结 果 ， 执 行 计划 和 统计 信息 。 
set autot trace: 该 命令 会 运行 SQL， 但 不 显示 运行 结果 ， 会 显示 执行 计划 和 统计 信息 。 
set autot trace exp: 运行 该 命令 查询 语句 不 执行 ，DML 语句 会 执行 ， 只 显示 执行 计划 。 
set autot trace stat: 该 命令 会 运行 SQL， 只 显示 统计 信息 。 
set autot off: 关闭 AUTOTRACE。 
我 们 使 用 set autot on 查看 执行 计划 (基于 OraclellgR2, Scott 账户 )。 
| 501> conn scott/tiger 
显示 已 连接 。 


SQL> set lines 200 pages 200 
SQL> set autot on 
SQL» select count(*) from emp; 


COUNT (*) 


50 





Plan hash value: 1006289799 


| Та | Operation | Name | Rows | Cost ($CPU)| Time | 
| 0 | SELECT STATEMENT | | 1 | 2 (0) | 00:00:01 | 
| 1 | SORT AGGREGATE | | LN | | 
| 2 | INDEX FAST FULL SCAN| РК ЕМР | 14 | 2 (0)1 09:00:01. | 
Note 

- dynamic sampling used for this statement (level-2) 
统计 信息 


233 recursive calls 
0 db block gets 
51 consistent gets 
10 physical reads 
0 redo size 
430 bytes sent via SQL*Net to client 
419 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
4 sorts (memory) 
0 sorts (disk) 
1 rows processed 


使 用 set autot on 查看 执行 计划 会 输出 SQL 运行 结果 ， 如 果 SQL 要 返回 大 量 结果 ， 我 
们 可 以 使 用 set autot trace 查看 执行 计划 ，set autot trace 不 会 输出 SQL 运行 结果 。 


SOL» set autot trace 
SQL» select count(*) from emp; 


Plan hash value: 1006289799 


| Id | Operation | Name | Rows | Cost ($CPU)| Time 

| 0 | SELECT STATEMENT | | i 2 (0)1 00:00:01 | 
| 1 | SORT AGGREGATE | | 1^4 | | 
| 2 1 INDEX FAST FULL SCAN| PK EMP | 14 | 2 (0)| 00:00:01 | 


- dynamic sampling used for this statement (level-2) 
统计 信息 

0 recursive calls 
0 db block gets 
4 consistent gets 
0 physical reads 
0 redo size 

430 bytes sent via SQL*Net to client 

419 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 


34 获取 执行 计划 常用 方法 


0 sorts (disk) 
l rows processed 


笔者 经 常 使 用 set autot trace 命令 查看 执行 计划 。 

利用 AUTOTRACE 查看 执行 计划 会 带 来 一 个 额外 的 好 处 ， 当 SQL 执行 完毕 之 后 , 会 在 执 
行 计划 的 末尾 显示 SQL 在 运行 过 程 中 耗费 的 一 些 统计 信息 。 

recursive calls 表示 递归 调用 的 次 数 。 一 个 SQL 第 一 次 执行 就 会 发 生硬 解析 ， 在 硬 解析 的 
时 候 ， 优 化 器 会 隐 含 地 调用 一 些 内 部 SQL， 因 此 当 一 个 SQL 第 一 次 执行 ，recursive calls 会 
于 0; 第 二 次 执行 的 时 候 不 需要 递归 调用 ，recursive calls 会 等 于 0。 

如 果 SQL 语句 中 有 自 定义 函数 ，recursive calls 永远 不 会 等 于 0， 自 定义 函数 被 调用 了 多 
少 次 ，recursive calls 就 会 显示 为 多 少 次 。 


SQL» create or replace function f getdname(v deptno in number) return varchar2 as 
2 v dname dept.dname$type; 


3 begin 

4 select dname into v dname from dept where deptno - v deptno; 
5 return v dname; 

6 end f getdname; 

JA Z 


Function created. 
SQL 多 次 执行 后 的 执行 计划 如 下 。 
SQL» select ename,f getdname(deptno) from emp; 


14 rows selected. 


Execution Plan 


Plan hash value: 3956160932 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time | 
| 0 | SELECT STATEMENT | | 14 | 126 | 3 (0) | 00:00:01 | 
| 1 | TABLE ACCESS FULL| EMP | 14 | 126 | 3 (0)| 00:00:01 
Statistics 

14 recursive calls 


0 db block gets 
36 consistent gets 
0 physical reads 
0 redo size 
769 bytes sent via SQL*Net to client 
419 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
14 rows processed 


SQL 一 共 返 回 了 14 行 数据 ， 每 返回 一 行 数据 ， 就 会 调用 一 次 自 定义 函数 ， 所 以 执行 计划 
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中 recursive calls 为 14. 

db block gets 表示 有 多 少 个 块 发 生变 化 ， 一 般 情 况 下 ， 只 有 DML 语句 才 会 导致 块 发 生变 
化 ， 所 以 查询 语句 中 db block gets 一 般 为 0。 如 果 有 延迟 块 清除 , 或 者 SQL 语句 中 调用 了 返回 
CLOB 的 函数 ，db block gets 也 有 可 能 会 大 于 0， 不 要 觉得 奇怪 。 

consistent gets 表示 逻辑 读 ， 单 位 是 块 。 在 进行 SQL 优化 的 时 候 ， 我 们 应 该 想方设法 减少 
逻辑 读 个 数 。 通常 情况 下 逻辑 读 越 小 , 性 能 也 就 越 好 。 需 要 注意 的 是 ， 逻辑 读 并 不 是 衡量 SQL 
执行 快慢 的 唯一 标准 ， 需 要 结合 ГО 等 其 他 综合 因素 共同 判断 。 

怎么 通过 逻辑 读 判断 一 个 SQL 还 存在 较 大 优化 空间 呢 ? WR SQL 的 逻辑 读 远 远 大 于 
SQL 语句 中 所 有 表 的 段 大 小 之 和 ( 假设 所 有 表 都 走 全 表 扫 描 ， 表 关联 方式 为 HASH JOIN ), 
那么 该 SQL 就 存在 较 大 优化 空间 。 动 手 能 力 强 的 读者 可 以 据 此 编写 一 个 SQL， 抓 出 SQL 3 
辑 读 远 远大 于 语句 中 所 有 表 段 大 小 之 和 的 SQL 语句 。 

physical reads 表示 从 磁盘 读 取 了 多 少 个 数据 块 ， 如 果 表 已 经 被 缓存 在 buffer cache 中 ， 没 
有 物理 读 ，physical reads 等 于 0。 

redo size 表示 产生 了 多 少 字 节 的 重 做 日 志 ， 一 般 情 况 下 只 有 DML 语句 才 会 产生 redo, ?r 
询 语句 一 般 情况 下 不 会 产生 redo， 所 以 这 里 redo size 为 0。 如 果 有 延迟 块 清除 ， 查 询 语句 也 会 
产生 redo。 

bytes sent via SQL*Net to client 表示 从 数据 库 服 务 器 发 送 了 多 少 字 节 到 客户 端 。 

bytes received via SQL*Net from client 表示 从 客户 端 发 送 了 多 少 字 节 到 服务 端 。 

SQL*Net roundtrips to/from client 表示 客户 端 与 数据 库 服务 端 交互 次 数 ， 我 们 可 以 通过 设 
置 arraysize 减少 交互 次 数 。 

sorts (memory) 和 sorts (disk) 分 别 表示 内 存 排 序 和 磁盘 排序 的 次 数 。 

rows processed 表示 SQL 一 共 返 回 多 少 行 数据 。 我 们 在 做 SQL 优化 的 时 候 最 关心 这 部 分 
数据 ， 因 为 可 以 根据 SQL 返回 的 行 数 判断 整个 SOL 应 该 是 走 HASH ЕЖ ЕЙ, 
如 果 rows processed 很 大 ， 一 般 走 HASH 连接 ; 如 果 rows processed Rh, MERET 


3.1.2 使 用 EXPLAIN PLAN FOR 查看 执行 计划 
使 用 explain plan for 查看 执行 计划 ， 用 法 如 下 。 


explain plan for SQL 语句 ; 
select * from table(dbms xplan.display); 


示例 COraclellgR2, Scott 账户 ) 如 下 。 
SOL> explain plan for select ename, deptno 

2 from emp 

3 where deptno in (select deptno from dept where dname = 'CHICAGO'); 
Explained. 
SOL» select * from table(dbms xplan.display); 


PLAN TABLE OUTPUT 


34 获取 执行 计划 常用 方法 


Plan hash value: 844388907 


| Та |Operation | Name | Rows | Bytes | Cost($CPU)| Time 

| 0 ISELECT STATEMENT | | Dri 110 1 6 (алу) 00200301 
| 1 | МЕВСЕ JOIN | | Т! T3006. 4| 6 HEMI 00:00:01 
|% 2 | TABLE ACCESS BY INDEX ROWID| DEPT | £ 诈 13 | 2 (0) | 00:00:01 
| Ead INDEX FULL SCAN | PX DEPT | 4 | | 1 (0) | 00:00:01 
І% 4 |. SORT.JOIN | | 14 | 126 | 4 (25)| 00:00:01 
| 5 uu TABLE ACCESS FULL | EMP | 14 | 126 | 3 (0) | 00:00:01 


Predicate Information (identified Бу operation id): 


2 - filter("DNAME"-'CHICAGO!') 
4 - access ("DEPTNO"-"DEPTNO") 
filter ("DEPTNO"-"DEPTNO") 


19 rows selected. 


查看 高 级 (ADVANCED) 执行 计划 ， 用 法 如 下 。 


explain plan for 501184); 
select * from table(dbms xplan.display(NULL, NULL, 'advanced -projection')); 


示例 COraclellgR2, Scott 账户 ) 如 下 。 
SQL> explain plan for select ename, deptno 
2 from emp 
3 where deptno in (select deptno from dept where dname = 'CHICAGO'); 


Explained. 


SQL» select * from table(dbms xplan.display(NULL, NULL, 'advanced -projection')); 


PLAN TABLE OUTPUT 


Plan hash value: 844388907 


| Id jOperation | Name | Rows | Bytes | Cost($CPU)| Time 

| 0 |SELECT STATEMENT | | 5| 110 | 6 (OY) 408009501 
| 1 | МЕВСЕ JOIN | | 5 | 110 | & (TL 00: 00:01 
|% 2 | TABLE ACCESS BY INDEX ROWID| DEPT | За AS. | 2 (0)| 00:00:01 
| 4 | INDEX FULL SCAN | PK DEPT "| 4 | | 1 (0) | 00:00:01 
|* 4 | SORT FOTN | | T4 | 126 | 4 (25)| 00:00:01 
| 5 | TABLE ACCESS FULL | EMP | 14 | i26 ] 3 (0)| 00:00:01 


SELS$5DA710D3 

SELS5DA710D3 / DEPTGSEL$S2 
SELS$5DA710D3 / DEPTGSELS2 
SEL$5DA710D3 / EMPGSELS1 
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и Атика с. 


Outline Data 


BEGIN_OUTLINE DATA 
PX JOIN FILTER(G"SEL$5DA710D3" "EMP"@"SEL$1") 
USE МЕҢСЕ(8"5ЕІ,65рА71003" "EMP"@"SEL$1") 
LEADING(@"SEL$5DA710D3" "DEPT"@"SEL$2" "EMP"@"SEL$1") 
FULL(@"SEL$5DA710D3" "EMP"@"SEL$1") 
INDEX (@"SEL$SDA710D3" "DEPT"@"SEL$2" ("DEPT"."DEPTNO")) 
OUTLINE (8"SEL$2") 
OUTLINE (G"SELS1") 
UNNEST (@"5Е192") 
OUTLINE LEAF (8"SEL$5DA710D3") 
ALL ROWS 
DB VERSION('11.2.0.1'") 
OPTIMIZER FEATURES ENABLE('10.2.0.3') 
IGNORE OPTIM EMBEDDED HINTS 
END OUTLINE DATA 
Ж 


Predicate Information (identified Бу operation ій): 


2 - filter("DNAME"-'CHICAGO') 
4 - access ("DEPTNO"-"DEPTNO") 
filter("DEPTNO"-"DEPTNO") 


48 rows selected. 


高 级 执行 计划 比 普 通 执行 计划 多 了 Query Block Name /Object Alias 和 Outline Data. 

当 需 要 控制 半 连 接 / 反 连接 执行 计划 的 时 候 ， 我 们 就 可 能 需要 查看 高 级 执行 计划 。 有 时 候 
我 们 需要 使 用 SQL PROFILE 固定 执行 计划 ， 也 可 能 需要 查看 高 级 执行 计划 。 

Query Block Name 表示 查询 块 名 称 ，Object Alias 表示 对 象 别名 。Outline Data 表示 SQL 
内 部 的 HINT. —4& SQL 语句 可 能 会 包含 多 个 子 查 询 ， 每 个 子 查询 在 执行 计划 内 部 就 是 一 个 
Query Block。 为 什么 会 有 Query Block W? 比如 一 个 SQL 语句 包含 有 多 个 子 查询 ， 假 如 每 个 
子 查 询 都 要 访问 同一 个 表 , 不 给 表 取 别名 ,这 个 时 候 我 们 怎么 区 分 表 属 于 哪个 子 查询 呢 ? 所 以 
Oracle 会 给 同一 个 SQL 语句 中 的 子 查询 取 别 名 ， 这 个 名 字 就 是 Query Block Name， 以 此 来 区 
分 子 查询 中 的 表 。Query Block Name 默认 会 命名 为 SEL$1，SEL$2，SEL$3 等 ， 我 们 可 以 使 用 
HINT: qb name (别名) 给 子 查 询 取 别名 。 

关于 高 级 执行 计划 更 为 详细 的 内 容 ， 请 阅读 本 书 5.6.2 节 。 


3.1.3 查看 带 有 A-TIME 的 执行 计划 
查看 带 有 A-TIME 的 执行 计划 的 用 法 如 下 。 


alter session set statistics level-all; 
或 者 在 SOL 语句 中 添加 hint:/** gather plan statistics */ 


运行 完 SQL 语句 ， 然 后 执行 下 面 的 查询 语句 就 可 以 获取 带 有 А-ТІМЕ 的 执行 计划 。 


| select * from table(dbms xplan.display cursor(null,null,'allstats last')); 


3.4 获取 执行 计划 常用 方法 


示例 COraclellgR2, Scott 账户 ) 如 下 。 


SQL» select /*+ gather plan statistics full(test) */ count(*) from test where owner-' 
SYS"'; 


COUNT (*) 


SQL» select * from table(dbms xplan.display cursor(null,null,'allstats last')); 


PLAN TABLE OUTPUT 


select /*+ gather plan statistics full(test) */ count(*) from test 
where owner-'SYS' 


Plan hash value: 1950795681 


| Id |Operation | Name | Starts | E-Rows | A-Rows | A-Time | Buffers | Reads | 
| 0 [SELECT STATEMENT | | 1| | 1 100:00:00.03 | 1037 | 1033 | 
| 1 | SORT AGGREGATE | | Te 1. 1 |00:00:00.03 | 1037 | 1033 | 
|%2 | TABLE ACCESS FULL| TEST | i] 2518 | 30808 |00:00:00.01 | 1037 | 1033 | 


Predicate Information (identified by operation id): 


2 = filter("OWNER"-'SYS') 


20 rows selected. 


Starts 表示 这 个 操作 执行 的 次 数 。 

E-Rows 表示 优化 器 估算 的 行 数 ， 就 是 普通 执行 计划 中 的 Rows. 

A-Rows 表示 真实 的 行 数 。 

A-Time 表示 累加 的 总 时 间 。 与 普通 执行 计划 不 同 的 是 ， 普 通 执行 计划 中 的 Time 是 假 的 ， 
而 A-Time 是 真实 的 。 

Buffers 表示 累加 的 逻辑 读 。 

Reads 表示 累加 的 物理 读 。 

上 面 介绍 了 З 种 方法 查看 执行 计划 。 使 用 AUTOTRACE 或 者 EXPLAIN PLAN FOR 获取 
的 执行 计划 来 自 于 PLAN TABLE. PLAN TABLE 是 一 个 会 话 级 的 临时 表 , 里面 的 执行 计划 并 
不 是 SQL 真实 的 执行 计划 ， 它 只 是 优化 器 估算 出 来 的 。 真 实 的 执行 计划 不 应 该 是 估算 的 ， 应 
该 是 真正 执行 过 的 。SQL 执行 过 的 执行 计划 存在 于 共享 池 中 ， 具 体 存在 于 数据 字典 
V$SQL PLAN 中 ， 带 有 A-Time 的 执行 计划 来 自 于 V$SQL _ PLAN， 是 真实 的 执行 计划 ， 而 通 
过 AUTOTRACE、 通 过 EXPLAIN PLAN FOR 获取 的 执行 计划 只 是 优化 器 估算 获得 的 执行 计 
划 。 有 读者 会 有 疑问 ,使 用 AUTOTRACE 查看 执行 计划 ，SQL 是 真正 运行 过 的 ， 怎 么 得 到 的 
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执行 计划 不 是 真实 的 呢 ? 原因 在 于 AUTOTRACE 获取 的 执行 计划 来 自 于 PLAN TABLE, 而 非 
来 自 于 共享 池 中 的 VS$SQL PLAN. 


3.1.4 查看 正在 执行 的 SQL 的 执行 计划 


有 时 需要 抓 取 正在 运行 的 SQL 的 执行 计划 , 这 时 我 们 需要 获取 SQL 的 SQL ID 以 及 SQL 
的 CHILD NUMEBR， 然 后 将 其 代入 下 面 SQL， 就 能 获取 正在 运行 的 SQL 的 执行 计划 。 


l select * from table(dbms xplan.display cursor('sql id',child number)); 


示例 COraclellgR2, Scott 账户 ) 如 下 。 
先 创建 两 个 测试 表 a，b。 
SQL» create table a as select * from dba objects; 


Table created. 
SOL» create table b as select * from dba objects; 


Table created. 


然后 在 一 个 会 话 中 执行 如 下 SQL。 


1 select count (*) from a,b where a.owner=b.owner; 


在 另外 一 个 会 话 中 执行 如 下 SQL， 结 果 如 图 3-1 所 示 。 


select a.sid, a.event, a.sql_id, a.sql_child number, b.sql_text 
from v$session а, v$sql b 

where a.sql address = b.address 
and a.sql hash value - b.hash value 
and a.sql child number = b.child number 

order by 1 desc; 








$8 SQL*NEt message from client | = achüjZbvtabtu | а E. 1 Oiselect a.sid, а, event, a.sql id, a.sql child number, b= 





33 db file scattered read = czr9jwxvOxra6 | O select count (+) from a,b where a.owner-b. owner - 
3-1 
接 下 来 我 们 将 SQL ID 和 CHILD. NUMBER 代入 以 下 SQL. 
SQL» select * from table(dbms xplan.display cursor('czr9jwxv0Oxra6',0)); 


PLAN TABLE OUTPUT 


SQL ID czr9jwxvO0xra6, child number 0 


select count(*) from a,b where a.owner-b.owner 


Plan hash value: 319234518 


| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%СРО)| Time 
| 0 | SELECT STATEMENT | | | | | 2556 (100) | | 
| 1 | SORT AGGREGATE | | Yi 34 | | | | 


3.2 ”定制 执行 计划 


pr m | HASH JOIN | | 400M| 126 |19208] 2556- (78)] 00:00:31 | 
| 2.1 TABLE ACCESS FULL| B | 67547 | 1121К| | 187 (1)| 00:00:03 
| 4 | TABLE ACCESS FULL| A | 77084 |  1279K]| |.. Ш9У (1) | 00:00:03 | 


- dynamic sampling used for this statement (level-2) 


在 Oracle 数据 库 中 ， 执 行 计划 是 树 形 结构 ， 因 此 我 们 可 以 利用 树 形 查 询 来 定制 执行 计划 。 
我 们 打开 PLSQL dev SQL 窗口 ， 登 录 示 例 账户 Scott 并 且 运 行 如 下 SQL. 


explain plan for select /*+ use hash(a,dept) */ * 
from emp a, dept 

where a.deptno - dept.deptno 
and a.sal » 3000; 


然后 执行 下 面 的 脚本 ， 结 果 如 图 3-2 所 示 。 


select case f 
when (filter predicates is not null or 


access predicates is not null) then 
(ж. 





else 
' ' 
end || id as "Та", 
lpad(' ', level) || operation || ' ' || options "Operation", 
object name "Name", 
cardinality as "Rows", 
filter predicates "Filter", 
access predicates "Access" 
from plan table 
Start with id = 0 
connect by prior id - parent id; 











TABLE ACCESS FULL “ЕР ©“ 


4 


S | TABLE ACCESS FULL - DEPT 





我 们 曾 在 1.2 节 中 提 到 ， 只 有 大 表 才 会 产生 性 能 问题 ， 因 此 可 以 将 表 的 段 大 小 添加 到 定制 
执行 计划 中 ， 这 样 我 们 在 用 定制 执行 计划 优化 SQL 的 时 候 ， 可 以 很 方便 地 知道 表 大 小 ， 从 而 
更 快 地 判断 该 步骤 是 否 可 能 是 性 能 瓶颈 。 下 面 脚 本 添加 表 的 段 大 小 以 及 索引 段 大 小 到 定制 执行 
计划 中 ， 结 果 如 图 3-3 所 示 。 


select case 
when (filter predicates is not null or 
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access_predicates is not null) then 
tt 


else 
' ' 
end || id as "та", 
lpad(' ', level) || operation || ' ' || options "Operation", 
object name "Name", 
cardinality as "Rows", 
b.size mb "Size Mb", 
filter predicates "Filter", 
access predicates "Access" 
from plan table a, 
(select owner, segment name, sum(bytes / 1024 / 1024) size mb 
from dba segments 
group by owner, segment name) b 
where a.object owner = b.owner(*) 
and a.object name = b.segment name (+) 
start with id - 0 
connect by prior id - parent id; 


如 图 3-3 所 示 ，Size Mb 显示 表 的 段 大 小 ， 单 位 是 МВ. 





RIA I 1. me [Rows [Size b Filter o 


0 =. SELECT STATEMENT eh | 1 k. | E эш MU IO 
$1 | НАН JON — — 20. УТЫ 1) | = “A”. “DEPTNO”=“DEPT”. "DEPTNO" 
*2 | TABLE ACCESS FULL “ЕР - l 0. 0625 “A”. " SAL" 53000 
3 “| TABLE ACCESS FULL “ЕРТ ~ 4 0. 0625! 
图 3-3 


我 们 曾 在 1.4 节 中 提 到 建立 组 合 索引 避免 回 表 或 者 建立 合适 的 组 合 索引 减少 回 表 次 数 。 如 
果 一 个 SQL 只 访问 了 某 个 表 的 极 少 部 分 列 ， 那 么 我 们 可 以 将 这 些 被 访问 的 列 联合 在 一 起 ， 从 
而 建立 组 合 索引 。 下 面 脚本 将 添加 表 的 总 字段 数 以 及 被 访问 字段 数量 到 定制 执行 计划 中 ,结果 
如 图 3-4 所 示 。 


select case 
when access predicates is not null or filter predicates is not null then 


жы үза 
е1зе 
' ' | | їа 
end as "Id", 
lpad(' ', level) || operation || ' ' || options "Operation", 


object name "Name", 
cardinality "Rows", 
b.size mb "Mb", 


case 
when object type like '$TABLES' then 
REGEXP COUNT(a.projection, ']') || '/' || c.column cnt 


end as "Column", 

access predicates "Access", 

filter predicates "Filter", 

case 
when object type like '$TABLE$' then 
projection 

end as "Projection" 

from plan table a, 

(select owner, segment name, sum(bytes / 1024 / 1024) size mb 
from dba segments 
group by owner, segment name) b, 


3.3 ”怎么 通过 查看 执行 计划 建立 索引 


(select owner, table_name, count(*) column_cnt 
from dba_tab_cols 
group by owner, table name) c 

where a.object owner = b.owner (+) 

and a.object name = b.segment name (+) 

and a.object owner = c.owner(*) 

and a.object name = c.table name (+) 
start with id = 0 
connect by prior id = parent id; 






.4JColumn [Access . — = ҚА 











*1 "| HASH JOIN 2 s 1 | 2747, *DEPTHO = DEPT.. "DEPTHO' э у __ 

#2 “| TABLE ACCESS FULL “EMP ~ 1. 0.0625 8/8 e 7|'A". "SAL'?3000 54 

3 "| TABLE ACCESS FULL — DEPT 4 0.0625 3/3 = ш "| 
图 3-4 


如 图 3-4 中 所 示 ，Column 表示 访问 了 表 多 少 列 / 表 一 共有 多 少 列 。Projection 显示 了 具体 的 
访问 列 信息 ， 限 于 书本 宽度 ， 图 中 没有 显示 Projection 列 信息 。 

限于 书本 限制 , 定制 执行 计划 本 书 不 做 进一步 讨论 ， 有 兴趣 的 读者 请 自行 添加 其 余 定制 信 
息 到 定制 执行 计划 中 。 






我 们 利用 如 下 SQL 讲解 (基于 OraclellgR2 scott)。 


SQL> explain plan for select e.ename,e.job,d.dname from emp e,dept d where e.deptno= 
d.deptno and e.sal«2000; 


Explained. 
SQL» select * from table(dbms xplan.display); 


PLAN TABLE OUTPUT 


Plan hash value: 615168685 


| 0 | SELECT STATEMENT | | 8 | | Ма OX OO:QUSOl | 
|% 1 | HASH JOIN | | 8 | 488 | 4c GS] 00:00:01 | 
| FT TABLE ACCESS FULL| DEPT | 4 | 88 | 3 (0) | 00:00:01 

| => | TABLE ACCESS FULL| EMP | 8 | | 3 (0) | 00:00:01 | 


Predicate Information (identified by operation id): 


1 = access("E"."DEPTNO"-"Dp". "DEPTNO") 
3 - filter("E","SATL"«2000) 


- dynamic sampling used for this statement (level-2) 
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执行 计划 分 为 两 部 分 ， Plan hash value 和 Predicate Information 之 间 这 部 分 主要 是 表 的 访问 
路 径 以 及 表 的 连接 方式 。 关 于 访问 路 径 以 及 表 连 接 方式 会 在 之 后 章节 详细 解释 。 另 外 一 部 分 是 
谓词 过 滤 信 息 ， 这 部 分 信息 位 于 Predicate Information 下 面 ， 谓 词 过 滤 信 息 非 常 重要 。 一 些 老 
ОВА 因为 之 前 接触 的 是 Oracle8i 或 者 Oracle9i， 那 个 时 候 执 行 计 划 还 没有 谓词 信息 ， 所 以 就 遗 
留 了 一 个 传统 ， 看 执行 计划 只 看 访问 路 径 和 表 连 接 方 式 了 ， 而 不 关心 谓词 过 滤 信息 。 还 有 些 人 
做 SQL 优化 喜欢 用 10 046 trace 或 者 10 053 trace， 如 果 仅 仅 是 优化 一 个 SQL， 根 本 就 不 需要 
使 用 上 面 两 个 工具 ， 直 接 分 析 SQL 语句 以 及 执行 计划 即 可 。 当 然 ， 如 果 是 为 了 深入 研究 为 什 
么 不 走 索引 ， 为 什么 走 了 网 套 循 环 而 没 走 HASH 连接 等 ， 这 个 时 候 我 们 可 以 用 10 053 trace: 
如 果 想 研究 访问 路 径 是 单 块 读 或 者 是 多 块 读 ， 可 以 使 用 10 046 trace, 

我 们 这 里 先 不 讲 怎么 阅读 执行 计划 ， 后 面 会 讲 利用 光标 移动 大 法 阅读 执行 计划 。 

注意 观察 Id 这 列 ， 有 些 qd 前 面 有 “*” 号 ， 这 表示 发 生 了 谓词 过 滤 ， 或 者 发 生 了 HASH 
连接 ,或 者 是 走 了 索引 。Id=1 前 面 有 “*” 号 ， 它 是 HASH 连接 的 “* ”号 ， 我 们 观察 对 应 的 
谓词 过 滤 信息 就 能 知道 是 哪 两 个 表 进 行 的 HASH 连接 ， 而 且 能 知道 是 对 哪些 列 进行 的 HASH 
连接 ， 这 里 是 e 表 (emp 表 的 别名 ) 的 deptno 列 与 d Æ (dept 的 别名 ) deptno 列 进行 HASH 
连接 的 。Id=3 前 面 有 “*” 号 ， 这 里 表示 表 emp 有 谓词 过 滤 ， 它 的 过 滤 条 件 就 是 Id=3 对 应 
的 谓词 过 滤 信 息 ， 也 就 是 e.sal<2000。Id=2 前 面 没有 “*” 号 ， 那 么 说 明 dept 表 没 有 谓词 
过 滤 条 件 。 

提问 : TABLE ACCESS FULL 前 面 没有 “*” 号 怎么 办 ? 


回答 : 如 果 表 很 小 ， 那 么 不 需 理 会 ， 小 表 不 会 产生 性 能 问题 。 如 果 表 很 大 ， 那 么 我 们 要 询 
问 开 发 人 员 是 不 是 忘 了 写 过 滤 条 件 ， 当 然 了 一 般 也 不 会 遇 到 这 种 情况 。 如 果真 的 是 没 过 滤 条 件 
H? 比如 一 个 表 有 10GB, 但 是 没有 过 滤 条 件 ， 那 么 它 就 会 成 为 整个 SQL 的 性 能 瓶颈 。 这 个 时 
候 我 们 需要 查看 SQL 语句 中 该 表 访问 了 多 少 列 ， 如 果 访 问 的 列 不 多 ， 就 可 以 把 这 些 列 组 合 起 
来 ,建立 一 个 组 合 索 引 , 索引 的 大 小 可 能 就 只 有 1GB 左右 。 我 们 利用 INDEX FAST FULL SCAN 
代替 TABLE ACCESS FULL。 在 访问 列 不 多 的 情况 ， 索 引 的 大 小 〈Segment Size) 肯定 比 表 的 
大 小 (Segment Size) 小 ， 那 么 就 不 需要 扫描 10GB 了 ， 只 需要 扫描 1GB， 从 而 达到 优化 目的 。 
WMR SQL 语句 里 面 要 访问 表 中 大 部 分 列 ， 这 时 就 不 应 该 建立 组 合 索引 了 ， 因 为 此 时 索引 大 小 
比 表 更 大 ， 可 以 通过 其 他 方法 优化 ， 比 如 开启 并 行 查询 , 或 者 更 改 表 连接 方式 ， 让 大 表 作 为 幅 
套 循环 的 被 驱动 表 ， 同 时 在 大 表 的 连接 列 上 建立 索引 。 关 于 表 连 接 方 式 , 我 们 会 在 后 面 章节 详 
细 介 绍 。 

提问 : TABLE ACCESS FULL 前 面 有 “*” 号 怎么 办 ? 


回答 : 如 果 表 很 小 , 那么 我 们 不 需 理会 ; 如 果 表 很 大 ， 可 以 使 用 “select count(*) from 32”, 
查看 有 多 少 行 数据 ， 然 后 通过 “select count(*) from Æ where * ”对 应 的 谓词 过 滤 条 件 ， 查 看 返 
回 多 少 行 数据 。 如 果 返 回 的 行 数 在 表 总 行 数 的 $5% 以 内 ， 我 们 可 以 在 过 滤 列 上 建立 索引 。 如 果 
已 经 存在 索引 ， 但 是 没 走 索引 ， 这 时 我 们 要 检查 统计 信息 ， 特 别 是 直方 图 信息 。 如 果 统 计 信 息 


3.3 ”怎么 通过 查看 执行 计划 建立 索引 


已 经 收集 过 了 ， 我 们 可 以 用 HINT 强制 走 索 引 。 如 果 有 多 个 谓词 过 滤 条 件 ， 我 们 需要 建立 组 合 
索引 并 且 要 将 选择 性 高 的 列 放 在 前 面 ,选择 性 低 的 列 在 后 面 。 如 果 返 回 的 行 数 超过 表 总 行 数 的 
5%， 这 个 时 候 我 们 要 查看 SQL 语句 中 该 表 访 问 了 多 少 列 ， 如 果 访 问 的 列 少 ， 同 样 可 以 把 这 些 
列 组 合 起 来 ， 建立 组 合 索引 ,建立 组 合 索 引 的 时 候 , 谓词 过 滤 列 在 前 面 ， 连 接 列 在 中 间 ，select 
部 分 的 列 在 最 后 。 如 果 访 问 的 列 多 ， 这 个 时 候 就 只 能 走 全 表 扫 描 了 。 

提问 : TABLE ACCESS BY INDEX КОМІР 前 面 有 “*” 号 怎么 办 ? 


回答 : 我 们 利用 如 下 SQL 讲解 (基于 Oracle11gR2 scott). 


| SOL» grant dba to scott; 


授权 成 功 。 

| SQL> create table test as select * from dba objects; 
表 已 创建 。 

| SQL» create index idx name оп test(object name); 
索引 已 创建 。 


SOL» set autot trace 

SQL» select /*+ index(test) */ * from test where object name like 'V $$' and owner-'S 
COTIL j 

未 选 定 行 


执行 计划 


Plan hash value: 461797767 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU) | Time 

| 0 | SELECT STATEMENT | | 38 | 7866 | 334 (0) | 00:00:05 | 
I* 1 | TABLE ACCESS BY INDEX ROWID| TEST | 38 | 7866 | 334 (0)| 00:00:05 
[5 12%”) INDEX RANGE SCAN | IDX NAME | 672 | | 6 (0) | 00:00:01 


1 - filter("OWNER"-'SCOTT') 
2 - access("OBJECT NAME" LIKE 'V $$") 
filter("OBJECT NAME" LIKE 'V $$!) 


- dynamic sampling used for this statement (level-2) 


统计 信息 


0 recursive calls 
0 db block gets 
332 consistent gets 
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ERR EAE, СЕ, 


0 physical reads 
0 redo size 

1191 bytes sent via SQL*Net to client 

409 bytes received via SQL*Net from client 

1 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
0 rows processed 


TABLE ACCESS BY INDEX КОМІ” 前 面 有 “*” 号 ， 表 示 回 表 再 过 波 。 回 表 再 过 滤 说 明 


数据 没有 在 索引 中 过 滤 干 净 。 当 TABLE ACCESS BY INDEX КОМІР 前 面 有 “*” 号 时 ， 可 以 
将 “*” 号 下 面 的 过 滤 条 件 包含 在 索引 中 ， 这 样 可 以 减少 回 表 次 数 ， 提 升 查 询 性 能 。 


SQL> create index idx ownername on test (owner,object name); 

索引 已 创建 

SOL» select /*+ index(test) */ * from test where object name like 'V 5%" and owner=' 
SCOTT' ; 


未 选 定 行 


执行 计划 


Plan hash value: 3756723214 


| Id |Operation | Name [Rows | Bytes | Cost($CPU)| Time | 
| 0 ISELECT STATEMENT | | 38| 7866 | 5 (0) 1 00:00:01 

| 1 | TABLE ACCESS BY INDEX ROWID|TEST | 38| 7866 | 5 (0) | 00:00:01 | 
I* 2 | INDEX RANGE SCAN |IDX OWNERNAME | 21 | 3 (0) | 00:00:01 | 


2 - access("OWNER"-'SCOTT' AND "OBJECT МАМЕ" LIKE 'V 5%") 
filter ("OBJECT NAME" LIKE 'V $$') 


- dynamic sampling used for this statement (level-2) 
统计 信息 
0 recursive calls 
0 db block gets 
3 consistent gets 
0 physical reads 
0 redo size 
1191 bytes sent via SQL*Net to client 
409 bytes received via SQL*Net from client 
1 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
0 rows processed 


如 果 索 引 返 回 的 数据 本 身 很 少 , 即使 TABLE ACCESS BY INDEX КОМІР 前 面 有 “*” 号 ， 
也 可 以 不 用 理会 ， 因 为 索引 本 身 返 回 的 数据 少 ， 回 表 也 没有 多 少 次 ， 因 此 可 以 不 用 再 创建 组 合 
索引 。 


3.4 运用 光标 移动 大 法 阅读 执行 计划 


通过 上 面 的 讲解 , 相信 大 家 也 明白 了 为 什么 我 们 不 推荐 使 用 工具 查看 执行 计划 , 因为 有 些 
工具 看 不 到 “*” 号 ， 看 不 到 谓词 过 小 信息 。 = 






m ащ I | 


执行 计划 中 ， 最 需要 关心 的 有 Id，Operation，Name，Rows。 

看 Id 是 为 了 观察 Id 前 面 是 否 有 “*” 号 。 

Operation 表示 表 的 访问 路 径 或 者 连接 方式 。 第 4 章 我 们 会 详细 介绍 常见 访问 路 径 ， 第 5 
章 会 详细 介绍 表 连 接 方式 。 

Name 是 SQL 语句 中 对 象 的 名 字 ， 可 以 是 表 名 、 索 引 名 、 视 图 名 、 物 化 视图 名 或 者 CBO 
自动 生成 的 名 字 。 

Rows 是 СВО 根据 统计 信息 以 及 数学 公式 计算 出 来 的 ， 也 就 是 说 Rows 是 假 的 , 不 是 真实 
的 。 这 里 的 Rows 也 被 称 作 执 行 计划 中 返回 的 基数 。 再 一 次 强调 ，Rows 是 假 的 ， 别 被 它 骗 了 。 
前 面 介绍 过 带 有 A-Time 的 执行 计划 , 带 有 A-Time 的 执行 计划 中 E-Rows 就 是 普通 执行 计划 中 
的 Rows，A-Rows 才 是 真实 的 。 在 进行 SQL 优化 的 时 候 ， 我 们 经 常 需要 手工 计算 某 个 访问 路 
径 的 真实 Rows， 然 后 对 比 执行 计划 中 的 Rows。 如 果 手 工 计 算 的 Rows 与 执行 计划 中 的 Rows 
相差 很 大 ， 执 行 计 划 往 往 就 出 错 了 。 

有 些 人 可 能 还 会 特意 查看 执行 计划 中 的 Cost， 在 进行 SQL 优化 的 时 候 ， 干 万 别 看 Cost! 
如 果 一 个 SQL 语句 都 需要 优化 了 ， 那 么 它 的 Cost 还 是 准确 的 吗 ? 有 很 大 概率 算 错 了 ! 既然 算 
错 了 ， 你 还 去 看 错误 的 Cost FIAR? 关于 Cost， 我 们 会 在 第 6 章 详细 介绍 ， 同 时 由 此 引出 





SQL 优化 核心 思想 。 
下 面 我 们 将 为 大 家 介绍 如 何 利用 光标 移动 大 法 阅读 执行 计划 。 
现 有 如 下 执行 计划 。 
| Id | Operation | Name | Rows | 
| 0 | SELECT STATEMENT | | 1-1 
] 1 | TABLE ACCESS BY INDEX ROWID | INTRC_PROD_DIM | Ze 
| 2 | NESTED LOOPS | | TI 
l 3] NESTED LOOPS | | 4 | 
| 4 | NESTED LOOPS | | 330 | 
| 571 NESTED LOOPS | | 131281 
|% 61 НА5Н JOIN | | -6558 | 
| a. | TABLE ACCESS FULL | INTRC_GEO_DIM | 2932 | 
[fs 28 4 HASH JOIN | 1^; $558: | 
|%: 78. 1 TABLE ACCESS FULL | INTRC_INITV_DIM | 833 
|* 19 | HASH JOIN | | 6558 | 
| 11.-1 PARTITION RANGE SINGLE | | 171 | 
AEZ TABLE ACCESS FULL | INTRC_TIME_DIM | 1717] 
p* 13 4 HASH JOIN | | 6558 
| 14 | PARTITION RANGE SINGLE | | 171 
Ж 157 | TABLE ACCESS FULL | INTRC TIME DIM | 717! 
(7:67) PARTITION RANGE SINGLE | | $558 | 
|” 27 | TABLE ACCESS FULL | INTRC_INITV TIME BRDG DIM | 6558 
| 18 | PARTITION RANGE SINGLE | | 200 
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тимаезоавы: БЕБЕ 1 


TABLE ACCESS BY LOCAL INDEX ROWID| INTRC INBR ЕСТ 





| | | | 
| %1 BITMAP CONVERSION ТО ROWIDS | | | 
|= 41/1 BITMAP INDEX FULL SCAN | INTRC INBR ЕСТ BX1 | | 
| 22 | PARTITION RANGE SINGLE | | 1 

Іш Эл] BITMAP CONVERSION ТО ROWIDS | | 1 

| 941 BITMAP AND | | | 
І% 25 | ВІТМАР INDEX SINGLE VALUE | INTRC TIME DIM BX1 | | 
[^29 BITMAP CONVERSION FROM ROWIDS | | | 
ү 22721 SORT ORDER BY | | | 
|* 28 | INDEX RANGE SCAN | INTRC TIME DIM PK | MET 
| 29 | BITMAP CONVERSION FROM ROWIDS | | | 
1% 30 | INDEX ВАМСЕ 5САМ | INTRC TIME DIM МХ1 | 1 | 
Е BITMAP CONVERSION ТО ROWIDS | | 1 

[532] BITMAP AND | | | 
4122.) ВІТМАР CONVERSION FROM ROWIDS | | | 
[+ 34 | INDEX RANGE SCAN | INTRC INPR BRDG DIM PK | 1—] 
1% 35 | BITMAP INDEX SINGLE VALUE | INTRC INPR BRDG DIM BX1 | | 
1% 36 | INDEX RANGE SCAN | INTRC PROD DIM PK | т 


有 些 读者 可 能 会 认为 Id=15 最 先 执行 ， 因 为 Id=15 的 缩 进 最 大 ， 其 实 这 是 错误 的 。 

现在 给 大 家 介绍 一 种 方法 : 光标 移动 大 法 。 光标 就 是 我 们 打字 的 时 候 ,， 鼠标 点 到 某 个 地 方 ， 
闪烁 的 光标 。 阅 读 执行 计划 的 时 候 ， 一 般 从 上 往 下 看 ， 找 到 执行 计划 的 入 口 之 后 ， 再 往 上 看 。 

阅读 执行 计划 的 时 候 ， 我 们 将 光标 移动 到 Id=0 SELECT 的 S 前 面 ， 然 后 按 住 键盘 的 向 下 
移动 的 箭头 ， 向 下 移动 ， 然 后 向 右 移 动 ， 然 后 再 向 下 ， 再 向 右 ……Id=0 和 Id=1 相差 一 个 空格 
〈 缩 进 )， 上 下 相差 一 个 空格 〈 缩 进 ) 就 是 父子 关系 ， 上 面 的 是 父亲 ， 下 面 的 是 儿子 ， 儿 子 比 父 
亲 先 执行 。 那 么 这 里 Id=1 是 Id=0 的 儿子 ，Id=1 先 执行 。Id=2 是 Id=1 的 儿子 ，Id=2 先 执行 。 
14-3 是 Id=2 的 儿子 ，Id=3 先 执行 。 这 样 我 们 一 直 将 光标 移动 到 Id=7 (向 下 ， 向 右 移 动 )，Id=7 
与 Id=8 对 齐 ， 表 示 Id=7 与 1d=8 是 兄弟 关系 ， 上 面 的 是 兄 ， 下 面 的 是 弟 ， 兄 优先 于 弟 先 执行 ， 
也 就 是 说 Id=7 先 于 Id=8 执行 。Id=7 也 跟 Id=19、Id=24、Id=34 对 齐 , 将 光标 移动 到 Id=7 前 面 ， 
向 下 移动 光标 , Id=19 在 Id=18 的 下 面 , 光标 移动 大 法 是 不 能 “ 穿 墙 ” 的， 从 Id=7 移动 到 14-19 
会 穿 过 Id=18， 同 理 Id=24、1d=34 th “Fia” T, AE Id=7 只 是 和 Id=8 对 齐 。 因 为 Id=7 F 
面 没有 儿子 ， 所 以 执行 计划 的 入 口 是 Id=7， 整 个 执行 计划 中 Id=7 最 先 执行 。 

提问 : 怎么 快速 找到 执行 计划 的 入 口 ? 


回答 : 我 们 可 以 利用 光标 移动 大 法 ， 先 将 光标 放 在 Id=0 这 一 步 ， 然 后 一 直 向 下 向 右 移 动 
光标 ， 直 到 找到 没有 儿子 的 14， 这 个 Id 就 是 执行 计划 的 入 口 。 


提问 : 怎么 判断 是 哪个 表 与 哪个 表 进 行 关联 的 ? 


回答 : 我 们 先 找到 表 在 执行 计划 中 的 4， 然后 看 这 个 Id (或 者 是 这 个 Id 的 父亲 ) 与 谁 对 
齐 〈 利 用 光标 上 下 移动 )， 它 与 谁 对 齐 ， 就 与 谁 进行 关联 。 比 如 Id=17 这 个 表 ， 它 本 身 没有 和 
任何 Id 对 齐 ， 但 是 Id=17 的 父亲 是 Id=16， 与 Id=14 对 齐 ，Id=14 的 儿子 是 Id=15， 所 以 Id=17 
这 个 表 是 与 Id=15 这 个 表 进 行 关 联 的 ， 并 且 两 个 表 是 进行 HASH 连接 的 。 


3.4 ”运用 光标 移动 大 法 阅读 执行 计划 
提问 : 在 SQL 优化 实战 中 ， 怎 么 应 用 光标 移动 大 法 优化 SQL? 


回答 : 例如 ， 有 如 下 执行 计划 。 














Id Operation Name | Starts E-Rows | A-Rows | A-Time 
1 | 1824 |00:02:42. 23 
1 1 1324 |00:02:42.23 
ҮМ NIVW 2 1 1 6808 00:02:42.18 | 
1 1 6808 00:02:42. 18 
1 5220К 00:02:21. 06 
1 1 5220К 00:02:00. 18 
1 1 5220К 00:01:49.74 
1 2 5220K 00:01:18.42 | 
1 1 6808 00:00:01. 62 
1 1 6808 00:00:00. 54 
1 ! 8 100:00:00. 40 
1 «КЕР соого 07 | 
1 47 5 00:00:00. 01 
1 25 00:00:00. 01 
ОРТ ACCT FDIM 25 47 25 |00:00:00.01 
OPT_ACCT ЕРІМ NX2 25 47 | 25 00:00:00. 01 
1 10482 | 12788 00:00:00. 03 
1 1 | 1 00:00:00. 01 
ж18 qt cue i OPT BUS UNIT FDIM UX2 1 i| 1 00:00:00. 01 
ж 19 ОРТ. BUS UNIT ЕРІМ UX2 1 Li 1 00:00:00. 01 
20 PARTITION PEST Hemaror 1 10482 | 12788 |00:00:00.03 
* 21 TABLE ACCESS F| OPT ACTVY FCT 1 10482 | 12788 |00:00:00.03 
* 22 TABLE ACCESS BY GLOBAL INDEX ROWID OPT PRMTN FDIM 11248 1 11248 ,00:00:00.31 | 
* 23 INDEX UNIQUE SCAN | OPT PRMTN FDIM PK 11248 1 11248 00:00:00. 12 
ж 24 TABLE ACCESS BY INDEX ROWID ОРТ CAL MASTR DIM 11248 1 6808 00:00:00. 14 
* 25 INDEX UNIQUE SCAN | OPT CAL | . MASTR. DIM PK 11248 1 11248 |00:00:00. 05 
26 PARTITION LIST ALL 6808 1 6808 00:00:01. 08 
* 27 TABLE ACCESS BY LOCAL INDEX ROWID OPT PRMTN FDIM 115K, 1 6808 00:00:01. 05 
* 28 INDEX RANGE SCAN ОРТ РЕМТУ FDIM NX3 115K 4| 6808 00:00:00. 78 
29 TABLE ACCESS BY GLOBAL INDEX ROWID T .PRMTN PROD FLTR LKP | 6808 39 5220K 00:01:19. 79 
* 30 INDEX RANGE SCAN PT PRMIN PROD FLTR LKP ХХ1 6808 3 5220K 00:00:43. 96 
* 31 TABLE ACCESS E қыз INDEX ROWID OPT _ACCT ЕРІМ |  8220K 1 5220К 00:00:23. 79 
ж 92 INDEX раи | ОРТ ACCT | _FDIM PK 5220К | 1, 5220К 00:00:08. 38 
本 33 | INDEX UNIQUE S | OPT CAL_MASTR_DIM PK |  8220K| 1| 5220К/00:00:07.58 | 
* 34 TABLE ACCESS Br Тох ROWID ~ ОРТ | CAL MASTR DIM _5220к) Lf 22 5220К 00:00:17. 28 





| 
I 
| 
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如 果 是 SQL 优化 初学 者 (高 手 可 以 以 一 眼看 出 执行 计划 哪里 有 性 能 问题 )， 可 以 先 利 用 光标 
移动 大 法 找到 执行 计划 入 口 ， 检 查 入 口 Rows 返回 的 真实 行 数 与 CBO 估算 的 行 数 是 否 存在 较 
大 差异 。 比 如 ， 这 里 执行 计划 入 口 为 It=15， 优 化 器 估算 返回 47 17 (E-Rows=47)， 实 际 上 返 
[| Y 25 ff (A-Rows=25), E-Rows 与 A-Rows 差别 不 大 。 找 到 执行 计划 入 口 之 后 ， 我 们 应 该 
从 执行 计划 入 口 往 上 检查 ，Id=15 上 面 的 是 Id=14，Id=14 上 面 的 是 Idt=13， 这 样 一 直 检查 到 
Id-11. Id-11 估算 返回 5 行 (E-Rows=5)， 但 是 实际 上 返回 了 11248 行 (A-Rows=11 248), 
所 以 执行 计划 Id=11 这 步 有 问题 ， 由 于 Id=11 Rows 估算 错误 ， 它 会 导致 后 面 整个 执行 计划 出 
错 ， 应 该 想 办 法 让 CBO 估算 出 较为 准确 的 Rows。 

我 们 还 可 以 利用 光标 移动 大 法 找 出 哪个 表 与 哪个 表 进 行 关联 的 ， 例 如 下 面 执行 计划 。 

Id=29 的 表 它 与 Id-8 对 齐 , 这 表示 Id=29 的 表 是 与 一 个 结果 集 进 行 关 联 的 ,关联 方式 为 嵌 
套 循环 (Id-7, NESTED LOOPS )。 从 执行 计划 中 我 们 可 以 看 到 Id=29 是 嵌 套 循环 的 被 驱动 表 ， 
但 是 没 走 索引 ， 走 的 是 全 表 扫 描 。 如 果 Id=29 的 表 是 一 个 大 表 ， 会 出 现 严 重 的 性 能 问题 ， 因 为 
它 会 被 扫描 多 次 ， 而 且 每 次 扫描 的 时 候 都 是 全 表 扫 描 ， 所 以 ， 我 们 需要 在 14-29 的 表 中 创建 一 
个 索引 【连接 列 上 创建 索引 )。 
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Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | Pstart| Pstop | 
0 | SELECT STATEMENT | L| 352 | 1551 (17)| 00:00:07 | 
1 | SORT GROUP BY 1 352 | 1551 (17) 00:00:07 
2 | VIEW | LNWVW_2 1| 352 | 1550 (17) 00:00:07 | 
3 HASH UNIQUE | 1 | 652| 1550 (17) 00:00:07 
4 NESTED LOOPS | | | 
5 NESTED LOOPS r| 652| 1549 (17) 00:00:07 | | 
6 NESTED LOOPS 1 639 | 1548 (17) 00:00:07 | 
7 NESTED LOOPS 2 1180 | 1546 (17) 00:00:07 
8 | STED LOOPS | 1 568 | 130  (8)| 00:00:01 
9 NESTED LOOPS | 1| 509| 109 (6) 00:00:01 | 
| 10 NESTED LOOPS 1| 484, 108 (б) 00:00:01 | 
* 11 HASH JOIN 5| 8390) 103 ie 00:00:01 
12 | PARTITION LIST SUBQUERY | 47 | 4089 82 (3) 00:00:01 |KEY(SQ) KEY(SQ) 
13 INLIST ITERATOR | | | | 
14 TABLE ACCESS BY LOCAL INDEX ROWID| ОРТ ACCT ЕРІМ 47 | 4089 | 82  (3)| 00:00:01 |KEY(SQ) KEY (SQ 
+ 18 | INDEX RANGE SCAN | OPT ACCT FDIM NX2 47 43 (5) 00:00:01 |KEY(SQ) KEY (SQ | 
16 | NESTED LOOPS 10482 | 8086 20 (15) 00:00:01 | 
| 17 NESTED LOOPS 1 40 2 (0) 00:00:01 
* 18 | INDEX RANGE SCAN OPT BUS UNIT FDIM UX2 | 1| % 1 (0) 00:00:01 
+19 | INDEX RANGE SCAN OPT BUS UNIT FDIM UX2 i| «| 1 (0) 00:00:01 | | 
20 PARTITION LIST ITERATOR | 10482 | 1699K| 18 (17) 00:00:01 | KEY KEY | 
|ж 21 TABLE ACCESS FULL | OPT ACTVY FCT | 10482 | 1699K, 18 (17) 00:00:01 KEY | KEY | 
|* 22 TABLE ACCESS BY GLOBAL INDEX ROWID | ОРТ PRMTN ЕРІМ | 1 318 | 1  (0)| 00:00:01 | ROWID | ROWID | 
* 22 | INDEX UNIQUE SCAN OPT PRMTN ЕРІМ PK 1| | 0 (0) 00:00:01 | | 
* 24 TABLE ACCESS BY INDEX ROWID OPT CAL MASTR DIM 1 25 | 1 (0) 00:00:01 | | 
* 25 INDEX UNIQUE SCAN OPT CAL MASTR DIM PK tal 0 (0) 00:00:01 | 
26 | PARTITION LIST ALL | ij 69|] 21 (0) 00:00:01 1 17 
|* 27 TABLE ACCESS BY LOCAL INDEX ROWID | OPT PRMIN ЕРІМ 1 59 | 21 (0) 00:00:01 | 1 17 
* 28 уйти | OPT PRMTN FDIM МХЗ | 4 17 (0) 00:00:01 | id с 
| 29 PARTITION LIST ITERATOR 39 | 858 1416 (18) 00:00:07 | KEY | KEY | 
* 30 | 39 | 858 | 1416 (18) 00:00:07 | KEY | KEY 
|ж 31 DEAE - NDEX ROWID PT'%wee+— | 1] 4 1 (0) 00:00:01 | ROWID | ROWID | 
|* 32 INDEX UNIQUE SCAN OPT АССТ ЕРІМ PK 1| 0 D 00:00:01 | | 
ж 33 TNDEX UNIQUE SCAN OPT CAL MASTR DIM PK | 1 0 (0) 00:00:01 | | 
ж 34 TABLE ACCESS BY INDEX ROWID OPT CAL MASTR DIM 1 13 1 (0)! 00:00:01 | 
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访问 路 径 指 的 就 是 通过 哪 种 扫描 方式 获取 数据 ， 比 如 全 表 扫 描 、 索 引 扫 描 或 者 直接 通过 
КОМІР 获取 数据 。 想 要 成 为 SQL 优化 高 手 , 我们 就 必须 深入 理解 各 种 访问 路 径 。 本 章 将 会 
细 介 绍 常见 的 访问 路 径 。 


wn \ 
m | 
É | ТШ US 


4.1.1 TABLE ACCESS FULL 


TABLE ACCESS FULL 表示 全 表 扫 描 ， 一 般 情 况 下 是 多 块 读 ，HINT: FULL( 表 名 /别名 )。 
等 待 事件 为 db file scattered read。 如 果 是 并 行 全 表 扫 描 ， 等 待 事件 为 direct path read, fE 
Oraclellg 中 有 个 新 特征 ,在 对 一 个 大 表 进 行 全 表 扫 描 的 时 候 ,会 将 表 直 接 读 入 PGA, 绕 过 buffer 
cache， 这 个 时 候 全 表 扫 描 的 等 待 事件 也 是 direct path read。 一 般 情况 下 ,我 们 都 会 禁用 该 新 特 
征 。 等 竺 事件 direct path read 在 开启 了 异步 I/O(disk_asynch io) 的 情况 下 统计 是 不 准确 的 。 关 
于 等 待 事件 ， 本 书 不 做 讨论 ， 那 毕竟 超出 了 本 书 范围 。 

因为 direct path read 统计 不 准 ， 所 以 我 们 在 编写 本 书 的 时 候 禁 用 了 direct path read, 


SQL» alter system set " serial direct read"-false; 









System altered. 


全 表 扫 描 究 竟 是 怎么 扫描 数据 的 呢 ? 回忆 一 下 Oracle 的 逻辑 存储 结构 ，Oracle 最 小 的 存 
储 单位 是 块 〈block)， 物 理 上 连续 的 块 组 成 了 区 (extent)， 区 又 组 成 了 段 (segment)。 对 于 非 
分 区 表 ， 如 果 表 中 没有 clob/blob 字段 ， 那 么 一 个 表 就 是 一 个 段 。 全 表 扫 描 ， 其 实 就 是 扫描 表 
中 所 有 格式 化 过 的 区 。 因 为 区 里 面 的 数据 块 在 物理 上 是 连续 的 ， 所 以 全 表 扫 描 可 以 多 块 读 。 全 
表 扫 描 不 能 跨 区 扫描 ， 因 为 区 与 区 之 间 的 块 物理 上 不 一 定 是 连续 的 。 对 于 分 区 表 ， 如 果 表 中 没 
有 clob/blob 字段 ， 一 个 分 区 就 是 一 个 段 ， 分 区 表 扫 描 方式 与 非 分 区 表 扫 描 方 式 是 一 样 的 。 

对 一 个 非 分 区 表 进 行 并 行 扫描 , 其 实 就 是 同时 扫描 表 中 多 个 不 同 区 , 因为 区 与 区 之 间 的 块 
物理 上 不 连续 ， 所 以 我 们 不 需要 担心 扫描 到 相同 数据 块 。 

对 一 个 分 区 表 进 行 并 行 扫描 ， 有 两 种 方式 。 如 果 需 要 扫描 多 个 分 区 ,那么 是 以 分 区 为 粒度 
进行 并 行 扫描 的 ， 这 时 如 果 分 区 数据 不 均衡 , 会 严重 影响 并 行 扫描 速度 ; 如 果 只 需要 扫描 单个 
分 区 ， 这 时 是 以 区 为 粒度 进行 并 行 扫描 的 。 

如 果 表 中 有 clob 字段 ，clob 会 单独 存放 在 一 个 段 中 ， 当 全 表 扫 描 需要 访问 clob 字段 时 ， 
这 时 性 能 会 严重 下 降 ， 因 此 尽量 避免 在 Oracle 中 使 用 clob。 我 们 可 以 考虑 将 clob 字段 拆 分 为 
多 个 varchar2 (4000) 字段 ， 或 者 将 clob 存放 在 nosql 数据 库 中 ， 例 如 mongodb。 
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一 般 的 操作 系统 ， 一 次 VO 最 多 只 支持 读 取 或 者 写 入 1MB 数据 。 数 据 块 为 8KB 的 时 候 ， 
一 次 VO 最 多 能 读 取 128 个 块 。 数据 块 为 16KB 的 时 候 , 一 次 VO 最 多 能 读 取 64 个 块 , 数据 块 
为 32KB 的 时 候 ， 一 次 IO 最 多 能 读 取 32 个 块 。 

如 果 表 中 有 部 分 块 已 经 缓存 在 buffer cache 中 ， 在 进行 全 表 扫 描 的 时 候 ， 扫 描 到 已 经 被 组 
存 的 块 所 在 区 时 ， 就 会 引起 IO 中 断 。 如 果 一 个 表 不 同 的 区 有 大 量 块 缓存 在 buffer cache 中 ， 
这 个 时 候 ， 全 表 扫 描 性 能 会 严重 下 降 ， 因 为 有 大 量 的 VO 中 断 ， 导 致 每 次 IO 不 能 扫描 1MB 
数据 。 

我 们 以 测试 表 test 为 例 ， 先 查看 测试 表 test 有 多 少 个 区 。 


select extent id,blocks, block id 
from dba extents 


3 where segment __ name = 'TEST' 
4 and owner = 'SCOTT'; 

EXTENT_ID BLOCKS BLOCK_ID 
0 8 528 

7 8 536 

2 8 544 

3 8 552 

4 8 560 

5 8 568 

6 8 576 

7 8 584 

8 8 592 

9 8 600 

10 8 608 

11 8 616 

12 8 624 

13 8 632 

14 8 640 

1:5 8 648 

16 128 768 

ҰЗ 128 896 

18 128 1024 

19 128 1152 

20 128 1280 

21 128 1408 

22 128 1536 

23 128 1664 


24 rows selected. 
测试 表 test 一 共有 24 个 区 ， 而 且 每 个 区 都 没有 超过 128 个 块 。 正常 情况 下 ， 对 测试 表 test 
进行 全 表 扫 描 需要 进行 24 次 多 块 读 。 现 在 我 们 清空 buffer cache 缓存 , 对 test 表 进 行 全 表 扫描 ， 
同时 使 用 10046 事件 监控 等 竺 事件 。 
SOL» show parameter db file multiblock 
db Fite Wuycipisek redd жыш Los Re 


SQL» alter system flush buffer cache; 
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System altered. 

SQL» alter session set events '10046 trace name context forever, level 8'; 
Session altered. 

SOL» select count(*) from test; 


COUNT (*) 


SQL» alter session set events '10046 trace name context off'; 


Session altered. 


下 面 是 经 过 tkprof 格式 化 后 的 10046 trace 文件 的 部 分 数据 。 


Rows Row Source Operation 


1 SORT AGGREGATE (cr=1037 pr=1033 pw=0 time=0 us) 


72462 TABLE ACCESS FULL TEST (cr=1037 pr=1033 pw=0 time=7795 us cost=289 size=0 c 
ard=72462) 


Elapsed times include waiting on following events: 


Event waited on Times Max. Wait Total Waited 
—— sas Walted ———— sss ¿Luc 
SQL*Net message to client 2 0.00 0.00 
Disk file operations I/O 1 0.00 0.00 
db file sequential read 1 0.00 0.00 
db file scattered read 24 0.00 0.01 
SQOL*Net message from client 2 ITLTO 11,10 


正如 我 们 猜想 的 那样 ， 全 表 扫 描 多 块 读 (db Не scattered read) 耗费 了 24 次 。 
现在 我 们 利用 下 面 SQL， 查 找 一 些 介 于 第 17 个 区 和 第 24 个 区 之 间 的 rowid。 


select rowid, 
dbms rowid.rowid relative fno(rowid) filet, 
dbms rowid.rowid block number(rowid) blocks 

from test; 


我 们 可 以 根据 block. id 为 边界 来 判断 rowid 在 哪个 区 。 
现在 我 们 清空 buffer cache， 选 取 4 个 不 同 区 的 rowid 访问 表 中 数据 ， 这 样 就 将 4 个 不 同 区 
的 块 缓存 在 buffer cache 中 了 , 然后 对 test 表 进 行 全 表 扫 描 , 同时 使 用 10046 事件 监控 等 待 事件 。 


SQL> alter system flush buffer cache; 
System altered. 


SQL> select count(*) 


2 from test 
3 where rowid іп ('AAASNJAAEAAAAMPAAk', 'AAASNJAAEAAAAQRAAn', 
4 'AAASNJAAEAAAAQ2AAR', 'AAASNJAAEAAAAUhAAM'); 
COUNT (*) 
4 


SOL» alter session set events '10046 trace name context forever, level 8'; 
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Session altered. 
SQL> select count(*) from test; 


COUNT (*) 


SOL» alter session set events '10046 trace name context off'; 


Session altered. 


下 面 是 经 过 tkprof 格式 化 后 的 10046 trace 文件 的 部 分 数据 。 


Rows Row Source Operation 


1 SORT AGGREGATE (cr=1037 pr=1029 pw=0 time=0 us) 
72462 TABLE ACCESS FULL TEST (cr=1037 pr=1029 pw=0 time=10479 us cost=289 size=0 
card=72462) 


Elapsed times include waiting on following events: 


Event waited on Times Max. Wait Total Waited 
нана Waited ---------- ------------ 
SQL*Net message to client 2 0.00 0.00 
db file sequential read 1 0.00 0.00 
db file scattered read 28 0.00 0.02 
SQOL*Net message from client 2 3.85 3.85 


因为 缓存 了 4 个 不 同 区 的 块 在 buffer cache H, 全 表 扫 描 的 时 候 需 要 中 断 4 VO, 所 以 全 
表 扫描 多 块 读 一 共 耗 费 了 28 次 。 
如 果 表 正在 发 生 大 事务 ， 在 进行 全 表 扫 描 的 时 候 ， 还 会 从 undo 读 取 部 分 数据 。 从 undo 
读 取 数据 是 单 块 读 ， 这 种 情况 下 全 表 扫 描 效 率 非常 低下 。 因 此 ,我 们 建议 使 用 批量 游标 的 方式 
处 理 大 事务 。 使 用 批量 游标 处 理 大 事务 还 可 以 减少 对 undo 的 使 用 ， 防 止 事务 失败 回 滚 太 慢 。 
以 示例 表 test 为 例 ， 我 们 先 在 一 个 会 话 中 更 新 表 中 所 有 数据 ， 模 拟 一 个 大 事务 。 
SQL» update test set owner-'SCOTT'; 
72462. rows updated. 
我 们 开启 另 一 个 会 话 ， 清 空 buffer cache 缓存 并 且 设 置 10046 事件 ， 然 后 运行 查询 。 
SQL» alter system flush buffer cache; 
System altered. 
SQL» alter session set events '10046 trace name context forever, level 8'; 
Session altered. 
SOL» select count(*) from test; 
COUNT (*) 


SQL» alter session set events '10046 trace name context off'; 
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| Session altered. 


下 面 是 经 过 tkprof 格式 化 后 的 10046 trace 文件 的 部 分 数据 。 


Rows Row Source Operation 


1 SORT AGGREGATE (cr=74531 pr=3380 pw=0 time=0 us) 


72462 TABLE ACCESS FULL TEST (cr=74531 pr=3380 pw=0 time=962057 us cost=289 size= 
0 card=72462) 


Elapsed times include waiting on following events: 


Event waited on Times Max. Wait Total Waited 
eei sss] Waited --е-“-<е---. mmm imme 
SOL*Net message to client 0.00 0.00 
Disk file operations I/O T, 0.00 0.00 
db file sequential read 2348 0.00 0.41 
db file scattered read 24 0.00 0.02 
SQOL*Net message from client 2 11.43 11.43 


db file sequential read 表示 单 块 读 ， 一 共 读 取 了 2 348 次 , 这 里 的 单 块 读 就 是 大 事务 产生 的 
undo 所 引起 的 。 

Oracle 行 存储 数据 库 在 进行 全 表 扫 描 时 会 扫描 表 中 所 有 的 列 。 关 于 行 存 储 与 列 存 储 本 书 将 
在 后 面 章节 介绍 。 


4.1.2 TABLE ACCESS BY USER ROWID 


TABLE ACCESS BY USER КОМІР” 表示 直接 用 КОМІР 获取 数据 ， 单 块 读 。 
该 访问 路 径 在 Oracle 所 有 的 访问 路 径 中 性 能 是 最 好 的 。 
我 们 以 测试 表 test 为 例 ， 运 行 下 面 SQL 并 且 查 看 执行 计划 。 

SOL» select * from test where rowid-'AAASNJAAEAAAAJqAA3'; 


Execution Plan 


Plan hash value: 1358188196 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time | 
| 0 | SELECT STATEMENT | | 1-4 gi. | 1 (0)] 00:00:01 
| 1 | TABLE ACCESS BY USER ROWID| TEST | d 97 | 1 (0)| 00:00:01 


在 where 条 件 中 直接 使 用 rowid 获取 数据 就 会 使 用 该 访问 路 径 。 


4.1.3 TABLE ACCESS BY ROWID RANGE 

TABLE ACCESS BY КОМІ” RANGE 表示 КОМІ” 范围 扫描 ， 多 块 读 。 因 为 同一 个 块 里 
面 的 ROWID 是 连续 的 ， 同 一 个 EXTENT 里 面 的 ROWID 也 是 连续 的 ， 所 以 可 以 多 块 读 。 

我 们 以 测试 表 test 为 例 ， 运 行 下 面 SQL 并 且 查 看 执行 计划 。 


| SOL» select * from test where rowid»-'AAASS5AAEAAB-*SLAAA!; 
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72462 rows selected. 
Execution Plan 


Plan hash value: 3472873366 


| Та | Operation | Name | Rows | Bytes | Cost ($CPU)| Time | 
| 0 | SELECT STATEMENT | | 3654 | 345К| 186 (1) | 00:00:03 
|% 1 | TABLE ACCESS BY ROWID RANGE| TEST | 3651 | 345K| 186 (1)| 00:00:03 


Predicate Information (identified by operation id): 


1 - access (ROWID»-'AAASSS5AAEAAB*SLAAA') 


where 条 件 中 直接 使 用 rowid 进行 范围 扫描 就 会 使 用 该 执行 计划 。 


4.1.4 TABLE ACCESS BY INDEX ROWID 


TABLE ACCESS BYINDEX ROWID 表示 回 表 ， 单 块 读 。 
我 们 在 第 1 章 中 提 到 过 回 表 ， 在 此 不 再 著述 。 


4.1.5 INDEX UNIQUE SCAN 


INDEX UNIQUE SCAN 表示 索引 唯一 扫描 ， 单 块 读 。 
对 唯一 索引 或 者 对 主键 列 进行 等 值 查找 ， 就 会 走 INDEX UNIQUE SCAN。 因 为 对 唯一 索 
引 或 者 对 主键 列 进行 等 值 查找 ，CBO 能 确保 最 多 只 返回 1 行 数据 ， 所 以 这 时 可 以 走 索引 唯一 
扫描 。 
我 们 以 scott 账户 中 emp 表 为 例 ， 运 行 下 面 SQL 并 且 查 看 执行 计划 。 
SQL> select * from emp where empno=7369; 


Execution Plan 


Plan hash value: 2949544139 


| Id | Operation | Name | Rows | Bytes | Cos t($CPU)| Time 

| 0 | SELECT STATEMENT | | W J 38 | 1 (0)| 00:00:01 
| va TABLE ACCESS BY INDEX ROWID| EMP | i 38 | 1 (09.4. "QD 00501 
ей | INDEX UNIQUE SCAN | PK EMP | T 0 (0)| 00:00:01 


2 - access ("ЕМРМО"=7369) 


因为 empno 是 主键 列 ， 对 empno 进行 等 值 访 问 ， 就 走 了 INDEX UNIQUE SCAN. 
INDEX UNIQUE SCAN 最 多 只 返回 一 行 数据 ， 只 会 扫描 “索引 高 度 ” 个 索引 块 ， 在 所 有 
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的 Oracle 访问 路 径 中 ， 其 性 能 仅 次 于 TABLE ACCESS BY USER ROWID。 


4.1.6 INDEX RANGE SCAN 


INDEX RANGE SCAN 表示 索引 范围 扫描 ， 单 块 读 ， 返 回 的 数据 是 有 序 的 (默认 升序 )。 
HINT: INDEX (〈 表 名 /别名 索引 名 )。 对 唯一 索引 或 者 主键 进行 范围 查找 ， 对 非 唯一 索引 进行 
等 值 查找 ， 范 围 查找 ， 就 会 发 生 INDEX RANGE SCAN。 等 待 事件 为 db file sequential read. 

我 们 以 测试 表 test 为 例 ， 运 行 下 面 SQL 并 且 查 看 执行 计划 。 

SQL> select * from test where object id-100; 


Execution Plan 


Plan hash value: 3946039639 


| Id | Operation | Name | Rows | Bytes | Cost (%СРО) | Time 

| 0 | SELECT STATEMENT | | T 1 97а] 2 (0) 1 00:00:01 | 
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 11 97 1 2 (0) | 00:00:01 
erm | INDEX RANGE SCAN | IDX ID | 1.1 | 1 (0) | 00:00:01 | 


2 - access("OBJECT ID"-100) 


因为 索引 IDX ID 是 非 唯一 索引 ， 对 非 唯一 索引 进行 等 值 查 找 并 不 能 确保 只 返回 一 行 数 
据 ， 有 可 能 返回 多 行 数据 ， 所 以 执行 计划 会 进行 索引 范围 扫描 。 

索引 范围 扫描 默认 是 从 索引 中 最 左边 的 叶子 块 开 始 ， 然 后 往 右边 的 叶子 块 扫描 ( 从 小 到 
大 )， 当 检查 到 不 匹配 数据 的 时 候 ， 就 停止 扫描 。 现 在 我 们 将 过 滤 条 件 改 为 小 于 ， 并 且 对 过 滤 
列 进行 降序 排序 ， 查 看 执行 计划 。 

SQL> select * from test where object id<100 order by object id desc; 


98 rows selected. 


Execution Plan 


Plan hash value: 1069979465 


| Id | Operation | Name | Rows | Bytes | Cost($CPU)| Time 

| 0 | SELECT STATEMENT | | 96 | 9312 | 4 (0) | 00:00:01 | 
| 1 | TABLE ACCESS BY INDEX ROWID | TEST | 96 | '9312-| 4 (0) | 00:00:01 
i^ 21 INDEX RANGE SCAN DESCENDING| IDX ID | 96 | | 2 (0)] 00:00:01 | 


2 - access ("ОВЈЕСТ ID"«100) 
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l filter("OBJECT ID"«100) 

INDEX RANGE SCAN DECENDING 表示 索引 降序 范围 扫描 ， 从 右 往 左 扫描 , 返回 的 数据 
是 降序 显示 的 。 

假设 一 个 索引 叶子 块 能 存储 100 行 数据 , 通过 索引 返回 100 行 以 内 的 数据 ， 只 扫描 “索引 
高 度 ” 个 索引 块 ， 如果 通过 索引 返回 200 行 数 据 ， 就 需要 扫描 两 个 叶子 块 。 通 过 索引 返回 的 行 
数 越 多 ,扫描 的 索引 叶子 块 也 就 越 多 ， 随 着 扫描 的 叶子 块 个 数 的 增加 ， 索 引 范围 扫描 的 性 能 
销 也 就 越 大 。 如 果 索 引 范 围 扫 描 需 要 回 表 ， 同 样 假设 一 个 索引 叶子 块 能 存储 100 行 数据 ,通过 
索引 返回 1000 行 数 据 ， 只 需要 扫描 10 个 索引 叶子 块 《 单 块 读 )， 但 是 回 表 可 能 会 需要 访问 几 
十 个 到 几 百 个 表 块 〈 单 块 读 )。 在 检查 执行 计划 的 时 候 我 们 要 注意 索引 范围 扫描 返回 多 少 行 数 
据 , 如 果 返 回 少量 数据 , 不 会 出 现 性 能 问题 ; 如 果 返 回 大 量 数据 , 在 没有 回 表 的 情况 下 也 还 好 ; 
如 果 返 回 大 量 数据 同时 还 有 回 表 , 这 时 我 们 应 该 考虑 通过 创建 组 合 索引 消除 回 表 或 者 使 用 全 表 
扫描 来 代替 它 。 


4.1.7 INDEX SKIP SCAN 


INDEX SKIP SCAN 表示 索引 跳跃 扫描 ， 单 块 读 。 返 回 的 数据 是 有 序 的 《默认 升序 )。 
HINT: INDEX SS (〈 表 名 /别名 索引 名 )。 当 组 合 索引 的 引导 列 《〈 第 一 个 列 ) 没有 在 where 条 
件 中 ， 并 且 组 合 索引 的 引导 列 / 前 几 个 列 的 基数 很 低 ，where 过 滤 条 件 对 组 合 索引 中 非 引 导 列 
进行 过 滤 的 时 候 就 会 发 生 索 引 跳 跃 扫描 ， 等 待 事件 为 db file sequential read. 

我 们 在 测试 表 test 上 创建 如 下 索引 。 


| SQL» create index idx ownerid on test(owner,object id); 





Index created. 

然后 我 们 删除 object id 列 上 的 索引 IDX. ID. 
SQL> drop index idx id; 
Index dropped. 

我 们 执行 如 下 SQL 并 且 查 看 执行 计划 。 
SOL» select * from test where object 14<100; 
98 rows selected. 
Execution Plan 


| Id |Орегабіоп | Name | Rows | Bytes | Cost($CPU)| Time | 
| 0 |SELECT STATEMENT- | | 96 | 9312 | 190 (0) | 00:00:02 
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 96 | 9312.) 100 (0) | 00:00:02 
|% 2 | INDEX SKIP SCAN | IDX OWNERID | 96 | | 97 (0) 1 00:00:02 
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Predicate Information (identified by operation id): 


2 - access("OBJECT ID"«100) 
filter("OBJECT ID"«100) 


从 执行 计划 中 我 们 可 以 看 到 上 面 SQL 走 了 索引 跳跃 扫描 。 最 理想 的 情况 应 该 是 直接 走 
where 条 件 列 object id 上 的 索引 ， 并 且 走 INDEX RANGE SCAN。 但 是 因为 where 条 件 列 上 面 
没有 直接 创建 索引 ， 而 是 间接 地 被 包含 在 组 合 索引 中 ， 为 了 避免 全 表 扫 描 ，CBO 就 选择 了 索 
引 跳 跃 扫描 。 

INDEX SKIP SCAN 中 有 个 SKIP 关键 字 ， 也 就 是 说 它 是 跳 着 扫描 的 。 那 么 想 要 跳跃 扫描 ， 
必须 是 组 合 索 引 , 如 果 是 单列 索引 怎么 跳 ? 另外 ,组 合 索引 的 引导 列 不 能 出 现在 where 条 件 中 ， 
如 果 引 导 列 出 现在 where 条 件 中 ， 它 为 什么 还 跳跃 扫描 呢 ， 直 接 INDEX RANGE SCAN 不 就 
可 以 了 ? 再 有 ， 要 引导 列 基数 很 低 ， 如 果 引 导 列 基数 很 高 ， 那 么 它 “ 跳 ”的 次 数 就 多 了 ， 性 能 
就 差 了 。 

当 执 行 计划 中 出 现 了 INDEX SKIP SCAN， 我 们 可 以 直接 在 过 滤 列 上 面 建 立 索 引 ， 使 用 
INDEX RANGE SCAN 代替 INDEX SKIP SCAN. 


4.1.8 INDEX FULL SCAN 


INDEX FULL SCAN 表示 索引 全 扫描 ， 单 块 读 ， 返 回 的 数据 是 有 序 的 〈 默 认 升 序 )。HINT: 
INDEX《〈 表 名 /别名 索引 名 )。 索 引 全 扫描 会 扫描 索引 中 所 有 的 叶子 块 〈 从 左 往 右 扫描 )， 如 果 
索引 很 大 ， 会 产生 严重 性 能 问题 (因为 是 单 块 读 )。 等 待 事件 为 db file sequential read. 

它 通常 发 生 在 下 面 3 种 情况 。 

> 分 页 语句 ， 分 页 语句 在 本 书 第 8 章 中 会 详细 介绍 ， 这 里 不 做 袭 述 。 

> SQL 语句 有 order by 选项 ，order by 的 列 都 包含 在 索引 中 ， 并 且 order by 后 列 顺 序 必 

须 和 索引 列 顺序 一 致 。order by 的 第 一 个 列 不 能 有 过 滤 条 件 ， 如 果 有 过 滤 条 件 就 会 走 
索引 范围 扫描 (INDEX RANGE SCAN)。 同 时 表 的 数据 量 不 能 太 大 (数据 量 太 大 会 走 
TABLE ACCESS FULL + SORT ORDER BY)。 我 们 有 如 下 SQL. 
| select * from test order by object id,owner; 

我 们 创建 如 下 索引 《索引 顺序 必须 与 排序 顺序 一 致 ， 加 0 是 为 了 让 索引 能 存 NULL). 

SOL» create index idx idowner on test(object id,owner,0); 

Index created. 
我 们 执行 如 下 SQL 并 上 且 查 看 执行 计划 。 

SQL» select * from test order by object id,owner; 

72462 rows selected. 

Execution Plan 


Plan hash value: 3870803568 
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| 0 |SELECT STATEMENT | | 73020 | 6916K|1338 (1)| 00:00:17 | 
| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 73020 | 6916К|1338 (1)| 00:00:17 
| 2 | INDEX FULL SCAN | IDX IDOWNER | 73020 | | 242 (1) 1 00:00:03 | 


> 在 进行 SORT MERGE JOIN 的 时 候 ， 如 果 表 数据 量 比较 小 ， 让 连接 列 走 INDEX FULL 
SCAN 可 以 避免 排序 。 例 子 如 下 。 
SOL» select /*+ use merge(e,d) */ 
i Tar emp e, dept d 
4 where e.deptno = d.deptno; 


14 rows selected. 


Execution Plan 


Plan hash value: 844388907 


| Id |Operation | Name | Rows | Bytes | Cost($CPU)| Time 

| 0 |SELECT STATEMENT | | 14 | 812 | 6 (17)| 00:00:01 | 
| 1 | MERGE JOIN | | 14 | 812 | 6. 1017) 100200501 | 
| 2 | TABLE ACCESS BY INDEX ROWID| DEPT | 4 | 80 | 2 (0)| 00:00:01 

|| „КДЖ INDEX FÜLL SCAN | PK DEPT | 4 | | 1 (0) | 00:00:01 
[* 4 |. SORT. JOIN | | 14 | 532 | 4 (25)| 00:00:01 | 
(25 | TABLE ACCESS FULL | EMP | 14 | 532 | 3 (0)| 00:00:01 


4 — access("E"."DEPTNO"-"D","DEPTNO") 
filter("E"."DEPTNO"-"p","DEPTNO") 


当 看 到 执行 计划 中 有 INDEX FULL SCAN， 我 们 首先 要 检查 INDEX FULL SCAN 是 否 有 
回 表 。 

WMR INDEX FULL SCAN 没有 回 表 , 我 们 要 检查 索引 段 大 小 , 如 果 索 引 段 太 大 (GB 级 别 )， 
应 该 使 用 INDEX FAST FULL SCAN fV INDEX FULL SCAN, 因 为 INDEX FAST FULL SCAN 
是 多 块 读 ，INDEX FULL SCAN 是 单 块 读 ， 即 使 使 用 了 INDEX FAST FULL SCAN 会 产生 额外 
的 排序 操作 ， 也 要 用 INDEX FAST FULL SCAN 代替 INDEX FULL SCAN. 

如 果 INDEX FULL SCAN 有 回 表 ， 大 多 数 情况 下 ， 这 种 执行 计划 是 错误 的 ， 因 为 INDEX 
FULL SCAN 是 单 块 读 ， 回 表 也 是 单 块 读 。 这 时 应 该 走 全 表 扫 描 ， 因 为 全 表 扫 描 是 多 块 读 。 如 
果 分 页 语句 走 了 INDEX FULL SCAN 然后 回 表 ， 这 时 应 该 没有 太 大 问题 ， 具 体 原因 请 大 家 阅 
读本 书 8.3 节 。 
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4.1.9 INDEX FAST FULL SCAN 


INDEX FAST FULL SCAN 表示 索引 快速 全 扫描 ， 多 块 读 。HINT: INDEX FFS C 4/9 
名 索引 名 )。 当 需要 从 表 中 查询 出 大 量 数据 但 是 只 需要 获取 表 中 部 分 列 的 数据 的 ,我 们 可 以 利 
用 索引 快速 全 扫描 代替 全 表 扫 描 来 提升 性 能 。 索 引 快速 全 扫描 的 扫描 方式 与 全 表 扫描 的 扫描 方 
式 是 一 样 , 都 是 按 区 扫描 , 所 以 它 可 以 多 块 读 , 而 且 可 以 并 行 扫描 。 等 待 事件 为 db file scattered 
read， 如 果 是 并 行 扫 描 ， 等 待 事件 为 direct path read. 

现 有 如 下 SQL。 


| select owner,object name from test; 
该 SQL 没有 过 滤 条 件 ， 默 认 情况 下 会 走 全 表 扫 描 。 但 是 因为 Oracle 是 行 存储 数据 库 ， 全 
表 扫 描 的 时 候 会 扫描 表 中 所 有 的 列 ， 而 上 面 查询 只 访问 表 中 两 个 列 ， 全 表 扫 描 会 多 扫描 额外 
13 个 列 ， 所 以 我 们 可 以 创建 一 个 组 合 索 引 ， 使 用 索引 快速 全 扫描 代替 全 表 扫 描 。 
SOL» create index idx ownername on test(owner,object name, 0); 
Index created. 
我 们 查看 SQL 执行 计划 。 
SQL> select owner,object_name from test; 
72462 rows selected. 


Execution Plan 


I Та | Operation | Name | Rows | Bytes | Cost($CPU)| Time | 
| 0 | SELECT STATEMENT | | 73020 | 2210K| 79 (2)1 00:00:01 | 
| Іт) INDEX FAST FULL SCAN| IDX OWNERNAME | 73020 | 2210К| 79 (2) 1 00:00:01 | 


现 有 如 下 SQL. 
i select object name from test where object id«100; 
该 SQL 有 过 滤 条 件 ， 根 据 过 滤 条 件 where object id«100 过 滤 数 据 之 后 只 返回 少量 
数据 ， 一 般 情况 下 我 们 直接 在 object id 列 创建 索引 ， 让 该 SQL 3E object id 列 的 索引 即 可 。 
SQL» create index idx id on test(object id); 
Index created. 
SQL» select object name from test where object id«100; 
98 rows selected. 
Execution Plan 


Plan hash value: 3946039639 
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| Id | Operation | Name | Rows | Bytes | Cost($CPU)| Time 

| 0 | SELECT STATEMENT | | 96 | 29800 4 (0) | 00:00:01 

| 1 | TABLE ACCESS BY INDEX ROWID| TEST | 96 | 2880 | 4 (0)| 00:00:01 
(LEN “| INDEX RANGE SCAN | IDX ID | 96 | | 2 (0) | 00:00:01 | 


Predicate Information (identified by operation id): 


2 - access("OBJECT ID"«100) 


Statistics 


0 recursive calls 
0 db block gets 
18 consistent gets 
0 physical reads 
0 redo size 
2217 bytes sent via SQL*Net to client 
485 bytes received via SQL*Net from client 
8 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
98 rows processed 


因为 该 SQL 只 查询 一 个 字段 ， 所 以 我 们 可 以 将 select 列 放 到 组 合 索 引 中 ， 避 免 回 表 。 | 
SOL» create index idx idname оп test(object id,object name); 
Index created. 

我 们 再 次 查看 SQL 的 执行 计划 。 
SOL» select object name from test where object id«100; 


98 rows selected. 


Execution Plan 


Plan hash value: 3678957952 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time 
| 0 | SELECT STATEMENT | | 96 | 2880 | 2 (0)) | 700:00%01 | 
kee. 032 | INDEX RANGE SCAN| IDX IDNAME | 96 |. 2880 | 2 (0)| 00:00:01 


Predicate Information (identified by operation id): 


1 - access("OBJECT ID"«100) 


Statistics 


0 recursive calls 
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0 db block gets 
9 consistent gets 
0 physical reads 
0 redo size 

2217 bytes sent via SQL*Net to client 

485 bytes received via SQL*Net from client 

8 SOQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
98 rows processed 


现 有 如 下 SQL. 
| select object name from test where object_id>100; 
以 上 SQL 过 滤 条 件 是 where object_id>100， 返 回 大 量 数据 ， 应 该 走 全 表 扫 描 ， 但 是 
因为 SQL 只 访问 一 个 字段 ， 所 以 我 们 可 以 走 索引 快速 全 扫描 来 代替 全 表 扫 描 。 
SQL» select object name from test where object id>100; 


72363 rows selected. 


Execution Plan 


Plan hash value: 252646278 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time 
| 0 | SELECT STATEMENT | |” 72924 |- 2136К| 73 (2)1 00:00:01 | 
|* 1 | INDEX FAST FULL SCAN| IDX IDNAME | 72924 | 2136К| 73 (2) 1 00200201. | 


1 - filter("OBJECT ID"2100) 


大 家 可 能 会 有 疑问 ， 以 上 SQL 能 否 走 INDEX RANGE SCAN 呢 ? INDEX RANGE SCAN 
是 单 块 读 , SQL 会 返回 表 中 大 量 数据 “几乎 ”会 扫描 索引 中 所 有 的 叶子 块 。INDEX FAST FULL 
SCAN 是 多 块 读 , 会 扫描 索引 中 所 有 的 块 ( 根 块 、 所 有 的 分 支 块 、 所 有 的 叶子 块 )。 虽然 INDEX 
RANGE SCAN 5 INDEX FAST FULL SCAN 相 比 扫描 的 块 少 (逻辑 读 少 ), 但 是 INDEX RANGE 
SCAN 是 单 块 读 , 耗费 的 /0 次 数 比 INDEX FAST FULL SCAN 的 IO 次 数 多 ,所 以 INDEX FAST 
FULL SCAN 性 能 更 好 。 

在 做 SQL 优化 的 时 候 ， 我 们 不 要 只 看 逻辑 读 来 判断 一 个 SQL 性 能 的 好 坏 ， 物 理 IO VOR 
比 逻 辑 读 更 为 重要 。 有 时 候 逻 辑 读 高 的 执行 计划 性 能 反而 比 逻 辑 读 低 的 执行 计划 性 能 更 好 ， 
为 逻辑 读 高 的 执行 计划 物理 IO 次 数 比 逻辑 读 低 的 执行 计划 物理 IO 次 数 低 。 

在 Oracle 数据 库 中 ，INDEX FAST FULL SCAN 是 用 来 代替 TABLE ACCESS FULL 的 。 
因为 Oracle 是 行 存储 数据 库 ，TABLE ACCESS FULL 会 扫描 表 中 所 有 的 列 ， 而 INDEX FAST 
FULL SCAN 只 需要 扫描 表 中 部 分 列 ，INDEX FAST FULL SCAN 就 是 由 Oracle 是 行 存储 这 个 
“缺陷 ”而 产生 的 。 
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Su ra MU semp 
如 果 数 据 库 是 Exadata, INDEX FAST FULL SCAN 几乎 没有 用 武之 地 ， 因 为 Exadata 是 行 
列 混合 存储 , 在 全 表 扫描 的 时 候 可 以 只 扫描 需要 的 列 (Smart Scan)， 没 必要 使 用 INDEX FAST 
FULL SCAN 来 代替 全 表 扫 描 。 如 果 我 们 在 Exadata 中 强行 使 用 INDEX FAST FUL SCAN ЖҰҚ 
替 全 表 扫 描 ， 反 而 会 降低 数据 库 性 能 ， 因 为 没 办 法 使 用 Exadata 中 的 Smart Scan. 
如 果 我 们 启用 了 12c 中 的 新 特性 IN MEMORY OPTION, INDEX FAST FULL SCAN JL 


乎 也 没有 用 武之 地 了 ， 因 为 表 中 的 数据 可 以 以 列 的 形式 存放 在 内 存 中 ， 这 时 直接 访问 内 存 中 
的 数据 即 可 。 


4.1.10 INDEX FULL SCAN ( MIN/MAX ) 


INDEX FULL SCAN (MIN/MAX) 表示 索引 最 小 /最 大 值 扫描 、 单 块 读 ， 该 访问 路 径 发 生 
在 SELECT MAX (COLUMN) FROM TABLE 或 者 SELECT MIN (COLUMN) FROM TABLE 
等 SQL 语句 中 。 

INDEX FULL SCAN (МІМ/МАХ) 只 会 访问 “索引 高 度 ” 个 索引 块 ， 其 性 能 与 INDEX 
UNIQUE SCAN 一 样 ， 仅 次 于 TABLE ACCESS BYUSER ROWID。 

现 有 如 下 SQL。 


| select max(object id) from t; 

该 SQL 查询 object id 的 最 大 值 ， 如 果 object id 列 有 索引 ， 索 引 默认 是 升序 排序 的 ， 这 时 
我 们 只 需要 扫描 索引 中 “最 右边 ”的 叶子 块 就 能 得 到 object id 的 最 大 值 。 现 在 我 们 查看 该 SQL 
的 执行 计划 。 

SQL> select max(object id) from t; 
Elapsed: 00:00:00.00 
Execution Plan 


| Id | Operation | Name | Rows | Bytes | Cost (%СРО) | Time 

| 0 | SELECT STATEMENT | 1: 0 SIP 186 (1)] 00:00:03 | 
| 1 |: SORT AGGREGATE | T Е 

y wm INDEX FULL SCAN db] IDX T ID | 67907 | 862K| | | 
Note 


- dynamic sampling used for this statement (level-2) 


Statistics 
0 recursivé calls 
0 db block gets 
2 consistent gets 
0 physical reads 
0 redo size 
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430 bytes sent via SQL*Net to client 
419 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
l rows processed 


现 有 另外 一 个 SQL。 


І select max(object_id),min(object_id) from t; 


iX SQL 要 同时 查看 object id 的 最 大 值 和 最 小 值 , 如 果 想 直接 从 object id 列 的 索引 获取 数 
据 ， 我 们 只 需要 扫描 索引 中 “最 左边 ”和 “最 右边 ”的 叶子 块 就 可 以 。 在 Btree 索引 中 ， 索 引 
叶子 块 是 双向 指向 的 ， 如 果 要 一 次 性 获取 索引 中 “最 左边 ”和 “最 右边 ”的 叶子 块 ， 我 们 就 需 
要 连带 的 扫描 “最 大 值 ”与 “最 小 值 ” 中 间 的 叶子 块 ， 而 本 案例 中 ， 中 间 叶 子 块 的 数据 并 不 是 
我 们 需要 的 。 如 果 该 SQL 走 索 引 ， 会 走 INDEX FAST FULL SCAN， 而 不 会 走 INDEX FULL 
SCAN, Kl» INDEX FAST FULL SCAN 可 以 多 块 读 ， 而 INDEX FULL SCAN 是 单 块 读 ， 两 者 
性 能 差距 巨大 (如 果 索 引 已 经 缓存 在 buffer cache 中 , +Ë INDEX FULL SCAN 与 INDEX FAST 
FULL SCAN 效率 几乎 一 样 ， 因为 不 需要 物理 1/0)。 需要 注意 的 是 , 该 SQL 没有 排除 object id 
为 NULL， 如 果 直 接 运 行 该 SQL， 不 会 走 索 引 。 

SQL> select max (object id),min(object id) from t; 


Elapsed: 00:00:00.02 


Execution Plan 


Plan hash value: 2966233522 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time 

| 0 | SELECT STATEMENT | | 1 | 13 | 186 (1) | 00:00:03 | 
l 1 | SORT AGGREGATE | | I ІЗ, | | | 
| 2 TABLE ACCESS FULL| T | 67907 | 862K| 186 (1)| 00:00:03 


我 们 排除 object id 为 NULL， 查 看 执行 计划 。 
SOL» select max(object id),min(object id) from t where object id is not null; 
Elapsed: 00:00:00.01 
Execution Plan 


Plan hash value: 3570898368 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time | 
| 0 | SELECT STATEMENT | | Y | X3 | 33 (4) 1 00:00:01 

| 1 | SORT AGGREGATE | | 12 | Larmi | | 
|н ЗА) INDEX FAST FULL SCAN| IDX T ID | 67907 | 862K| 33 (4)1 00:00:01 | 


Predicate Information (identified by operation id): 
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- dynamic sampling used for this statement (level=2) 


Statistics 


0 recursive calls 
0 db block gets 
169 consistent gets 
0 physical reads 
0 redo size 
501 bytes sent via SQL*Net to client 
419 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
l rows processed 


从 上 面 的 执行 计划 中 我 们 可 以 看 到 SQL ÆT INDEX FAST FULL SCAN, INDEX FAST 
FULL SCAN 会 扫描 索引 段 中 所 有 的 块 ， 理 想 的 情况 是 只 扫描 索引 中 “最 左边 ”和 “最 右边 ” 
的 叶子 块 。 现 在 我 们 将 该 SQL 改写 为 如 下 SQL。 
| select (select max(object id) from t), (select min(object id) from t) from dual; 

我 们 查看 后 的 执行 计划 。 

SQL» select (select max(object id) from t), (select min(object id) from t) from dual; 
Elapsed: 00:00:00.01 
Execution Plan 


Plan hash value: 3622839313 


| Id | Operation | Name | Rows | Bytes | Cost($CPU)| Time 

| 0 | SELECT STATEMENT | | 4:7) | 2 (0) | 00:00:01 | 
| 1 | SORT AGGREGATE l | 1. 1 ESG | | 
(97827! INDEX FULL SCAN (МІМ/МАХ)| IDX Т ID | 67907 | 862K| | | 
| 3 | SORT AGGREGATE | | ІІ 13 | | | 
| 4| INDEX FULL SCAN (MIN/MAX)| IDX T ID | 67907 | 862K| | | 
| 5 | FAST DUAL | | < N. | 2 (0) 1 00:00:01 | 


- dynamic sampling used for this statement (level=2) 


Statistics 


0 recursive calls 
0 db block gets 
4 consistent gets 
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0 physical reads 
0 redo size 
527 bytes sent via SQL*Net to client 
419 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
1 rows processed 
原始 SQL 因为 需要 1 次 性 从 索引 中 取得 最 大 值 和 最 小 值 ， 所 以 导致 走 了 INDEX FAST 
FULL SCAN。 我 们 将 该 SQL 进行 等 价 改 写 之 后 ， 访 问 了 索引 两 次 ， 一 次 取 最 大 值 ， 一 次 取 最 


小 值 ， 从 而 避免 扫描 不 需要 的 索引 叶子 块 ， 大 大 提升 了 查询 性 能 。 
4.1.11 MAT. VIEW REWRITE ACCESS FULL 


МАТ VIEW REWRITE ACCESS FULL 表示 物化 视图 全 表 扫 描 、 多 块 读 。 因 为 物化 视图 本 
质 上 也 是 一 个 表 ， 所 以 其 扫描 方式 与 全 表 扫描 方式 一 样 。 如 果 我 们 开局 了 查询 重 写 功 能 ， 而 且 
SQL 查询 能 够 直接 从 物化 视图 中 获得 结果 ， 就 会 走 该 访问 路 径 。 

现在 我 们 创建 一 个 物化 视图 TEST MV. 


SQL» create materialized view test mv 
2 build immediate enable query rewrite 
3 as select object id,object name from test; 


Materialized view created. 


有 如 下 SQL 查询 。 
| select object id,object name from test; 
因为 物化 视图 TEST MV 已 经 包含 查询 需要 的 字段 ， 所 以 该 SQL 会 直接 访问 物化 视图 
TEST MV. 
SQL> select object_id,object name from test; 


72462 rows selected. 


Execution Plan 


Plan hash value: 1627509066 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU) | Time | 
| 0 | SELECT STATEMENT | | 67036 | 5171К| 65 (2) 1 00:00:01 | 
| Kaul MAT_VIEW REWRITE ACCESS FULL| TEST_MV | 67036 | 5171K| 65 (2) |00; 00:01 | 






单 块 读 与 多 块 读 这 两 个 概念 对 于 掌握 SQL 优化 非常 重要 , 更 准确 地 说 是 单 块 读 的 物理 IO 
次 数 和 多 块 读 的 物理 VO 次 数 对 于 掌握 SQL 优化 非常 重要 。 
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第 4 章 访问 路 径 ( ACCESS PATH ) 


从 磁盘 1 次 读 取 1 个 块 到 buffer cache 就 叫 单 块 读 ， 从 磁盘 1 次 读 取 多 个 块 到 buffer cache 
就 叫 多 块 读 。 如 果 数 据 块 都 已 经 缓存 在 buffer cache 中 ， 那 就 不 需要 物理 1O 了 ， 没 有 物理 IO 
也 就 不 存在 单 块 读 与 多 块 读 。 

绝 大 多 数 的 平台 , — VO 最 多 只 能 读 取 或 者 写 入 IMB ЖЖ, Oracle 的 块 大 小 默认 是 8k, 
那么 一 次 VO 最 多 只 能 写 入 128 个 块 到 磁盘 , 最 多 只 能 读 取 128 个 块 到 buffer cache. 在 判断 哪 
个 访问 路 径 性 能 好 的 时 候 ， 通常 是 估算 每 个 访问 路 径 的 10 次数; 谁 的 1/0 次 数 少 , 谁 的 性 能 
就 好 。 在 估算 UO 次 数 的 时 候 ， 我 们 只 需要 算 个 大 概 就 可 以 了 ， 没 必要 很 精确 。 


ТЕ 为 什么 有 时 候 素 引 扫描 比 全 表 扫描 更 慢 


假设 一 个 表 有 100 万 行 数 据 ， 表 的 段 大 小 为 1GB。 如 果 对 表 进 行 全 表 扫 描 ， 最 理想 的 情况 
下 ， 每 次 VO 都 读 取 1MB 数据 (128 个 块 )， 将 1GB 的 表 从 磁盘 读 入 buffer cache 需要 1 024 
次 IO。 在 实际 情况 中 ， 表 的 段 前 16 个 extent， 每 个 extent 都 只 有 8 个 块 ， 每 次 IO 只 能 读 取 
8 个 块 ， 而 不 是 128 个 块 ， 表 中 有 部 分 块 会 被 缓存 在 buffer cache 中 ， 会 引起 IO 中 断 ， 那 么 将 
1GB 的 表 从 磁盘 读 入 buffer cache 可 能 需要 耗费 1 500 次 物理 VO. 

从 表 中 查询 5 万 行 数据 ,， 走 索引 。 假 设 一 个 索引 叶子 块 能 存储 100 行 数据 ， 那 么 5 万 行 数 
据 需 要 扫描 500 个 叶子 块 〈 单 块 读 )， 也 就 是 需要 500 次 物理 UO, Жн 5 万 条 数据 需要 回 
表 , 假设 索引 的 集群 因子 很 小 (接近 表 的 块 数 ), 假设 每 个 数据 块 存储 50 行 数据 ， 那 么 回 表 需 
要 耗费 1000 次 物理 ПО ( 单 块 读 )， 也 就 是 说 从 表 中 查询 5 万 行 数据 ， 如 果 走 索引 ， 一共 需 要 
耗费 大 概 1 500 次 物理 UO。 如 果 索 引 的 集群 因子 较 大 《接近 表 的 总 行 数 )， 那 么 回 表 要 耗费 更 
多 的 物理 UO， 可 能 是 3 000 次 ， 而 不 是 1 000 次 。 

根据 上 述 理论 我 们 知道 , 走 索 引 返 回 的 数据 越 多 ， 需 要 耗费 的 VO 次 数 也 就 越 多 ,因此 ， 
返回 大 量 数据 应 该 走 全 表 扫 描 或 者 是 INDEX FAST FULL SCAN， 返 回 少量 数据 才 走 索引 扫 
Ji. 根据 上 述 理 论 ， 我 们 一 般 建议 返回 表 中 总 行 数 5% 以 内 的 数据 ， 走 索引 扫描 ， 超 过 5% 走 
全 表 扫 描 。 请 注意 ，5% 只 是 一 个 参考 值 ， 适 用 于 绝 大 多 数 场 景 ， 如 有 特殊 情况 ， 具 体 问 题 
具体 分 析 。 


[T] ом 对 于 索引 维护 的 影响 


本 节 主 要 讨论 DML 对 于 索引 维护 的 影响 。 

在 OLTP 高 并 发 INSERT 环境 中 ， 递 增 列 〈 时 间 ， 使 用 序列 的 主键 列 ) 的 索引 很 容易 引起 
索引 热点 块 争 用 。 递 增 列 的 索引 会 不 断 地 往 索引 “最 右边 ”的 叶子 块 插入 最 新 数据 《因为 索引 
默认 升序 排序 )， 在 高 并 发 INSERT 的 时 候 ， 一 次 只 能 由 一 个 SESSION 进行 INSERT， 其 余 
SESSION 会 处 于 等 待 状态 ， 这 样 就 引起 了 索引 热点 块 争 用 。 对 于 递增 的 主键 列 索引 ， 我 们 可 
以 对 这 个 索引 进行 反 转 (reverse)， 这 样 在 高 并 发 INSERT 的 时 候 ， 就 不 会 同时 插入 索引 “最 
右边 ”的 叶子 块 ， 而 是 会 均衡 地 插入 到 各 个 不 同 的 索引 叶子 块 中 ,这 样 就 解决 了 主键 列 索引 的 
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热点 块 问题 。 将 索引 进行 反 转 之 后 ， 索 引 的 集群 因子 会 变 得 很 大 〈 基 本 上 接近 于 表 的 总 行 数 )， 
此 时 索引 范围 扫描 回 表 会 有 严重 的 性 能 问题 。 但 是 一 般 情 况 下 ， 主 键 列 都 是 等 值 访问 ， 索 引 走 
的 是 索引 唯一 扫描 (ONDEX UNIQUE SCAN)， 不 受 集 群 因 子 的 影响 ， 所 以 对 主键 列 索引 进行 
反 转 没有 任何 问题 。 对 于 递增 的 时 间 列 索引 ， 我 们 不 能 对 这 个 索引 进行 反 转 ， 因 为 经 常会 对 时 
间 字 段 进行 范围 查找 ， 对 时 间 字 段 的 索引 反 转 之 后 ， 索 引 的 集群 因子 会 变 得 很 大 ,严重 影响 回 
表 性 能 。 过 到 这 种 情况 , 我们 应 该 考虑 对 表 根 据 时 间 进 行 范围 分 区 ,利用 分 区 裁剪 来 提升 查询 
性 能 而 不 是 在 时 间 字 段 建 立 索引 来 提升 性 能 。 

在 OLTP 高 并 发 INSERT 环境 中 ， 非 递增 列 索引 《比如 电话 号 码 ) 一 般 不 会 引起 索引 热点 
块 争 用 。 非 递增 列 的 数据 都 是 随机 的 (电话 号 码 )， 在 高 并 发 INSERT 的 时 候 ， 会 随机 地 插入 
到 索引 的 各 个 叶子 块 中 , 因此 非 递 增 列 索引 不 会 引起 索引 热点 块 问 题 ,但 是 如 果 索 引 太 多 会 严 
重 影响 高 并 发 INSERT 的 性 能 。 

HRA 1 个 会 话 进行 INSERT 时 ， 表 中 会 有 1 个 块 发 生变 化 ， 有 多 少 个 索引 ， 就 会 有 多 少 
个 索引 叶子 块 发 生变 化 “不 考虑 索引 分 裂 的 情况 )， 假 设 有 10 个 索引 ， 那 么 就 有 10 个 索引 叶 
子 块 发 生变 化 。 如 果 有 10 个 会 话 同时 进行 INSERT， 这 时 表 中 最 多 有 10 个 块 会 发 生变 化 ， 索 
引 中 最 多 有 100 个 块 会 发 生变 化 (10 个 SESSION 与 10 个 索引 相 乘 )。 在 高 并 发 的 INSERT Ж 
境 中 ， 表 中 的 索引 越 多 ，INSERT 速度 越 慢 。 对 于 高 并 发 INSERT， 我 们 一 般 是 采用 分 库 分 表 、 
读 写 分 离 和 消息 队列 等 技术 来 解决 。 

ТЕ OLAP 环境 中 ， 没 有 高 并 发 INSERT 的 情况 ， 一 般 是 单 进 程 做 批量 INSERT。 单 进程 做 
批量 INSERT， 可 以 在 递增 列 上 建立 索引 。 因 为 是 单 进 程 ， 没 有 并 发 ， 不 会 有 索引 热点 块 争 用 ， 
数据 也 是 一 直 插 入 的 索引 中 “最 右边 ”的 叶子 块 ， 所 以 递增 列 索引 对 批量 INSERT 影响 不 会 太 
大 。 单 进程 做 批量 INSERT， 不 能 在 非 递增 列 建 立 索 引 。 因 为 批量 INSERT 几乎 会 更 新 索引 中 
所 有 的 叶子 块 ， 所 以 非 递 增 列 索引 对 批量 INSERT 影响 很 大 。 在 OLAP 环境 中 ， 事 实 (БАСТ) 
表 没 有 主键 ， 时 间 列 一 般 也 是 分 区 字段 ， 所 以 递增 列 上 面 一 般 是 没有 索引 的 ， 而 电话 号 码 等 非 
递增 列 往往 需要 索引 ， 为 了 提高 批量 INSERT 的 效率 ， 我 们 可 以 在 INSERT 之 前 先 禁 止 索 引 ， 
等 INSERT 完成 之 后 再 重建 索引 。 
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第 5 童 “ 表 连接 方式 


本 章 是 本 书 核心 章节 ， 和 希望 大 家 反复 阅读 本 章 内 容 ， 直 到 全 部 掌握 为 止 。 

R (结果 集 ) GR ERR) 之 间 的 连接 方式 非常 重要 ， 如 果 СВО 选择 了 错误 的 连接 方 
式 ， 本 来 几 秒 就 能 出 结果 的 SQL 可 能 执行 一 天 都 执行 不 完 。 如 果 想 要 快速 定位 超大 型 SQL 性 
能 问题 ， 我 们 就 必须 深入 理解 表 连 接 方式 。 在 多 表 关 联 的 时 候 , 一 般 情况 下 只 能 是 两 个 表 先 关 
联 ， 两 表 关 联 之 后 的 结果 再 和 其 他 表 / 结 果 集 关 联 ， 如 果 执行 计划 中 出 现 了 Filter， 这 时 可 以 一 
次 性 关联 多 个 表 。 


EZ) жаи (шнш) | 


ВУ J SEE: 驱动 表 返 回 一 行 数据 , 通过 连接 列传 值 给 被 驱动 表 , 驱动 表 返 回 多 少 行 ， 
被 驱动 表 就 要 被 扫描 多 少 次 。 

幅 套 循环 可 以 快速 返回 两 表 关 联 的 前 几 条 数据 ,如 果 SQL 中 添加 了 HINT: FIRST ROWS, 
在 两 表 关 联 的 时 候 ， 优 化 器 更 倾向 于 媒 套 循环 。 

媒 套 循环 驱动 表 应 该 返回 少量 数据 。 如 果 驱 动 表 返 回 了 100 万 行 , 那么 被 驱动 表 就 会 被 扫 
fi 100 万 次 。 这 个 时 候 SQL 会 执行 很 入 ， 被 驱动 表 会 被 误 认 为 热点 表 ， 被 驱动 表 连 接 列 的 索 
引 也 会 被 误 认 为 热点 索引 。 

骨 套 循环 被 驱动 表 必 须 走 索引 。 如 果肉 套 循环 被 驱动 表 的 连接 列 没 包含 在 索引 中 , 那么 被 
驱动 表 就 只 能 走 全 表 扫 描 ， 而 且 是 反复 多 次 全 表 扫 描 。 当 被 驱动 表 很 大 的 时 候 ，SQL 就 执行 
不 出 结果 。 

巾 套 循环 被 驱动 表 走 索 引 只 能 走 INDEX UNIQUE SCAN 或 者 INDEX RANGE SCAN. 

媒 套 循环 被 驱动 表 不 能 走 TABLE ACCESS FULL， 不 能 走 INDEX FULL SCAN， 不 能 走 
INDEX SKIP SCAN， 也 不 能 走 INDEX FAST FULL SCAN. 

拒 套 循环 被 驱动 表 的 连接 列 基 数 应 该 很 高 。 如 果 被 驱动 表 连 接 列 的 基数 很 低 ， 那 么 被 驱 
动 表 就 不 应 该 走 索 引 ， 这 样 一 来 被 驱动 表 就 只 能 进行 全 表 扫 描 了 ， 但 是 被 驱动 表 也 不 能 走 全 
KAH 

两 表 关 联 返回 少量 数据 才能 走 藤 套 循环 。 前 面 提 到 ， 航 套 循环 被 驱动 表 必 须 走 索引 ， 如 果 
两 表 关联 ， 返回 100 万 行 数据 ， 那 么 被 驱动 表 走 索引 就 会 产生 100 万 次 回 表 。 回 表 一 般 是 单 块 
读 ， 这 个 时 候 SQL 性 能 极 差 ， 所 以 两 表 关 联 返 回 少量 数据 才能 走 典 套 循环 。 

我 们 在 测试 账号 scott 中 运行 如 下 SQL. 

SQL> select /*+ gather_plan_statistics use_nl(e,d) leading(e) */ 


e.ename, e.job, d.dname 
3 from emp e, dept d 
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| 4 where e.deptno = d.deptno; 


我 们 运行 下 面 命 令 获 取 带 有 A-TIME 的 执行 计划 。 
SQL» select * from table(dbms xplan.display cursor(null,null,'ATLSTATS LAST')); 


PLAN TABLE OUTPUT 


select /** gather plan statistics use nl(e,d) leading(e) */ е.епапе, 
e.job, d.dname from emp e, dept d where e.deptno = d.deptno 


Plan hash value: 3625962092 


| Id | Operation | Name |Starts|E-Rows|A-Rows|  A-Time | Buffers| 
| 0 | SELECT STATEMENT | | 1| | 14|00:00:00.01| 26 | 
| Jj NESTED LOOPS | | 1| | 14|00:00:00.01| 26 | 
| o2-1 NESTED LOOPS | | 1] 15] 14|00:00:00.01| 12” | 
| 2 | TABLE ACCESS FULL | EMP | 11 15| 14|00:00:00.01| 8 

К^ 4 | INDEX UNIQUE SCAN | PK DEPT| 14| 1| 14|00:00:00.01| 4 

Ме TABLE ACCESS BY INDEX ROWID|DEPT | 14| Ti 14|00:00:00.01| 14, ! 


4 = access ("E","DEPTNO"-"D", "DEPTNO") 


在 执行 计划 中 ， 离 NESTED LOOPS 关键 字 最 近 的 表 就 是 驱动 表 。 这 里 EMP 就 是 驱动 表 ， 
DEPT 就 是 被 驱动 表 。 

驱动 表 EMP 扫描 了 一 次 (Id=3，Starts=1)， 返 回 了 14 行 数据 (1d=3，A-Row)， 传 值 14 
次 给 被 驱动 表 (Id=4)， 被 驱动 表 扫 描 了 14 次 (Id=4，Id=5，Starts=14)。 

ТН ДЕК ЕДЕН PLSQL 代码 实现 。 


declare 
Cursor cur emp is 
select ename, job, deptno from emp; 
v dname dept.dname$type; 
begin 
for x in cur emp loop 
select dname into v dname from dept where deptno = x.deptno; 
dbms output.put line(x.ename ||." ' || x.job || ' ' [|| v dname); 
end loop; 
end; 


游标 cur emp 就 相当 于 驱动 表 EMP， 扫 描 了 一 次 ， 一 共 返 回 了 14 条 记录 。 该 游标 循环 了 
14 次 ， 每 次 循环 的 时 候 传 值 给 dept, dept 被 扫描 了 14 次 。 
为 什么 峰 套 循环 被 驱动 表 的 连接 列 要 创建 索引 呢 ? 我 们 注意 观察 加 粗 部 分 的 PLSQL 代码 。 


declare 
cursor cur_emp is 
select ename, job, deptno from emp; 
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第 5 章 表 连 接 方式 
v_dname dept.dname$type; 
begin 
for x in cur_emp loop 
select dname into v_dname from dept where deptno = X tno; 
dbms output.put _ line(x.ename || ' ' || x. jeb MW" st Су_апате); 


епа 1оор; 
епа; 


因为 扫描 被 驱动 表 dept 次 数 为 14 次 , 每 次 需要 通过 deptno 列传 值 , 所 以 嵌 套 循环 被 驱动 
表 的 连接 列 需 要 创建 索引 。 

虽然 本 书 不 讲 PLSQL 优化 ， 但 是 笔者 见 过 太 多 的 PLSQL 垃圾 代码 ， 因 此 ， 提 醒 大 家 ， 
在 编写 PLSQL 的 时 候 ， 尽 量 避 免 游 标 循环 里 面 套 用 SQL， 因 为 那 是 纯 天 然 的 供 套 循环 。 假 如 
游标 返回 100 万 行 数据 ， 游 标 里 面 的 SQL 会 被 执行 100 万 次 。 同 样 的 道理 ， 游 标 里 面 尽 量 不 
要 再 套 游标 ， 如 果 外 层 游标 循环 1 万 次 ， 内 层 游标 循环 1 万 次 ， 那 么 最 里 面 的 SQL 将 被 执行 
一 亿 次 。 

当 两 表 使 用 外 连接 进行 关联 ， 如 果 执 行 计划 是 走 岁 套 循环 ， 那 么 这 时 无 法 更 改 驱动 表 ， 驱 
动 表 会 被 固定 为 主 表 ， 例 如 下 面 SQL. 

А explain plan for select /*+ use nl(d,e) leading(e) */ 


3 from dept d 
4 left join emp e on d.deptno = e.deptno; 


Explained. 
SQL» select * from table(dbms xplan.display); 
PLAN TABLE OUTPUT 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time 

| 0 | SELECT STATEMENT | | 14 | 812 | 8 (0)| 00:00:01 | 
| 1 | NESTED LOOPS OUTER| | 14 | 812 | 8 (0) | 00:00:01 | 
| 2] TABLE ACCESS FULL| DEPT | 4 | 80 | 3 (0)| 00:00:01 | 
[E -3ь! TABLE ACCESS FULL| EMP | A | 152 | 1 (0)] 00:00:01 | 


3 - filter("D"."DEPTNO"-"E","DEPTNO" (+) ) 


15 rows selected. 


use п(а,е zs iE Pi КЕЙЕМ, 在 书写 HINT 的 时 候 ， 如 果 表 有 别名 ，HINT 中 一 定 要 
使 用 别名 ， 否 则 HINT 不 生效 ， 如 果 表 没有 别名 ，HINT 中 就 直接 使 用 表 名 。 

leading(e) 表 示 让 EMP 表 作 为 驱动 表 。 

从 执行 计划 中 我 们 可 以 看 到 , DEPT 与 EMP 是 采用 顽 套 循环 进行 连接 的 ,这 说 明 use nl(d,e) 
生效 了 。 执 行 计划 中 驱动 表 为 DEPT, BARA T leading(e)， 但 是 没有 生效 。 

为 什么 leading(e) 没 有 生效 呢 ? 因为 DEPT 与 EMP 是 外 连接 , DEPT 是 主 表 , EMP 是 从 表 ， 
外 连接 走 嵌 套 循环 的 时 候 驱 动 表 只 能 是 主 表 。 


5.1 WEHA ( NESTED LOOPS ) 
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值 ， 主 表 传 值 给 从 表 之 后 ， 如 果 发 现 从 表 没 有 关联 上 ， 直 接 显 示 为 NULL 即 可 ; 但 是 如 果 是 
从 表 传 值 给 主 表 ， 没 关联 上 的 数据 不 能 传 值 给 主 表 ， 不 可 能 传 NULL 给 主 表 ， 所 以 两 表 关联 
是 外 连接 的 时 候 ， 走 嵌 套 循环 驱动 表 只 能 固定 为 主 表 。 

需要 注意 的 是 ， 如 果 外 连接 中 从 表 有 过 滤 条 件 ， 那么 此 时 外 连接 会 变 为 内 连接 , 例如 下 面 
SQL. 

SQL» select /%% leading(e) use nl(d,e) */ * 

2 from dept d 


3 left join emp e on d.deptno = e.deptno 
4 where e.sal « 3000; 


11 rows selected. 


Execution Plan 


| Id |Operation | Name | Rows | Bytes | Cost (%CPU)| Time 

| 0 |5ЕШЕСТ STATEMENT | | 221 696 | ЕЗ (0) | 00:00:01 | 
| 1 | NESTED ІООР5 | | 12 | 696 | 15 (0) | 00200401 | 
|% 2 | TABLE ACCESS FULL | EMP | 12.1 456 | 3 (0)] 00:00:01 

| 3 | TABLE ACCESS BY INDEX ROWID| DEPT | Lu 20 | Е) (0) 1 00:00:01 
(Жад 1 INDEX UNIQUE 5САМ | PK DEPT | Ly | 0 (0) | 00:00:01 | 


2 = filter("E"."SAL"«3000) 
4 - access("D"."DEPTNO"-"E","DEPTNO") 


HINT 指定 了 让 从 表 EMP 作为 嵌 套 循环 驱动 表 ， 从 执行 计划 中 我 们 看 到 ，EMP 确实 是 作 
为 仍 套 循环 的 驱动 表 ， 而 且 执行 计划 中 没有 OUTER 关键 字 ， 这 说 明 SQL 已 经 变 为 内 连接 。 

为 什么 外 连接 的 从 表 有 过 滤 条 件 会 变 成 内 连接 呢 ? 因为 外 连接 的 从 表 有 过 滤 条 件 已 经 排除 
了 从 表 与 主 表 没有 关联 上 显示 为 NULL 的 情况 。 

提问 : 两 表 关 联 走 不 走 NL 是 看 两 个 表 关 联 之 后 返回 的 数据 量 多 少 ?还 是 看 驱动 表 返 回 的 
数据 量 多 少 ? 


回答 : 如 果 两 个 表 是 1 : N 关系 ， 驱 动 表 为 1， 被 驱动 表 为 N 并且 N 很 大 ， 这 时 即使 驱动 
表 返 回 数 据 量 很 少 ,也 不 能 走 嵌 套 循环 ， 因 为 两 表 关 联 之 后 返回 的 数据 量 会 很 多 。 所 以 判断 两 
表 关 联 是 否 应 该 走 NL 应 该 直接 查看 两 表 关 联 之 后 返回 的 数据 量 , 如 果 两 表 关 联 之 后 返回 的 数 
据 量 少 ， 可 以 走 NL; 返回 的 数据 量 多 ， 应 该 走 HASH 连接 。 

提问 : KARETI UREA (NL) 驱动 表 ? 
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eo 
回答 : 可 以 ， 如 果 大 表 过 滤 之 后 返回 的 数据 量 很 少 就 可 以 当 NL 驱动 表 。 
іні: select * from a,b where a.id-b.id; 如 果 a 有 100 条 数据 ，b 有 100 7j 
行 数据 ，a 与 b 是 1:N 关 系 ，N 很 低 ， 应 该 怎么 优化 SQL? 


回答 : 因为 a 与 b 是 1 :NN 关系, МИК, 我 们 可 以 在 b 的 连接 列 Gd) 上 创建 索引 ， ika 
Ej b EREMI Ca nl b, 这 样 b 表 会 被 扫描 100 次 , 但 是 每 次 扫描 表 的 时 候 走 的 是 id 列 的 索 
5| (范围 扫描 )。 如 果 让 a 和 b 进行 HASH 连接 ，b 表 会 被 全 表 扫 描 (因为 没有 过 滤 条 件 )， 需 
要 查询 表 中 100 万 行 数据 ， 而 如 果 让 a 和 ЖЫТ ЖД, b 表 只 需要 查询 出 表 中 最 多 几 百 行 
数据 (100*N)。 一 般 情况 下 ， 一 个 小 表 与 一 个 大 表 关 联 ， 我 们 可 以 考虑 让 小 表 NL KE, KE 
走 连 接 列 索引 〈 如 果 大 表 有 过 滤 条 件 ， 需 要 将 过 滤 条 件 与 连接 列 组 合 起 来 创建 组 合 索 引 )， 从 
而 避免 大 表 被 全 表 扫 描 。 

最 后 ， 为 了 加 深 对 舱 套 循环 的 理解 ， 大 家 可 以 在 SQLPLUS 中 依次 运行 以 下 脚本 ， 观 察 
SQL 执行 速度 ， 思 考 SQL 为 什么 会 执行 缓慢 ， 


create table a as select * from dba objects; 

create table b as select * from dba objects; 

set timi on 

set lines 200 pages 100 

set autot trace 

select /*+ use nl(a,b) */ * from a,b where a.object id-b.object id; 


Xd). РАЖАА nb ЗАЛ ЕСЕДЕН, PEOR |а SOR NEIGE HASH 
连接 。 

HASH 连接 的 算法 : 两 表 等 值 关 联 ， 返 回 大 量 数 据 ， 将 较 小 的 表 选 为 驱动 表 ， 将 驱动 表 的 
“select 列 和 join 列 ” 读 入 PGA 中 的 work area, 然后 对 驱动 表 的 连接 列 进行 hash 运算 生成 hash 
table， 当 驱动 表 的 所 有 数据 完全 读 入 РСА 中 的 work area 之 后 ， 再 读 取 被 驱动 表 (被 驱动 表 不 
需要 读 入 PGA 中 的 work area), 对 被 驱动 表 的 连接 列 也 进行 hash 运算 , 然后 到 PGA 中 的 work 
area 去 探测 hash table， 找 到 数据 就 关联 上 ， 没 找到 数据 就 没 关 联 上 。 哈 希 连 接 只 支持 等 值 连 
接 。 

我 们 在 测试 账号 scott 中 运行 如 下 SQL。 

SQL» select /*+ gather plan statistics use hash(e,d) %/ 
e.ename, e.job, d.dname 


3 from emp e, dept d 
4 where e.deptno = d.deptno; 
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我 们 运行 如 下 命令 获取 执行 计划 。 


| SQL» select * from table(dbms_xplan.display_cursor(null,null,'ALLSTATS LAST')); 


5.2 HASH 连接 ( HASH JOIN ) 


PLAN TABLE OUTPUT 


select /*+ gather plan statistics use hash(e,d) %/ е.епате, e.job, 
d.dname from emp e, dept d where e.deptno - d.deptno 


Plan hash value: 615168685 


| Id |Operation |Name|Starts|E-Rows|A-Rows | A-Time  |Buffers|OMem|1Mem|Used-Mem| 
| 0 |SELECT STATEMENT | | 11 | 14|00:00:00.01| 15| | 

|* 1 | HASH JOIN | | 1| 18] 14|00:00:00.01| 15|888К|888К| 714К(0) 
| 2 | TABLE ACCESS FULL|DEPT | 1| 4| 4|00:00:00.01| i» | 

| 3 | TABLE ACCESS FULL|EMP | 1| 15] 14|00:00:00.01| 8| | | 


1 = access("E"."DEPTNO"-"D"."DEPTNO") 


执行 计划 中 离 HASH 连接 关键 字 最 近 的 表 就 是 驱动 表 。 这 里 DEPT 就 是 驱动 表 ，EMP 就 
是 被 驱动 表 。 驱 动 表 DEPT 只 扫描 了 一 次 (Id=2，Starts=1)， 被 驱动 表 EMP 也 只 扫描 了 一 次 
(Id=3，Starts=1)。 再 次 强调 ， 购 套 循环 被 驱动 表 需 要 扫描 多 次 ，HASH 连接 的 被 驱动 表 只 需 
要 扫描 一 次 。 

Used-Mem 表示 HASH 连接 消耗 了 多 少 PGA， 当 驱动 表 太 大 、PGA 不 能 完全 容纳 驱动 表 
时 ， 驱 动 表 就 会 溢出 到 临时 表 空 间 ， 进 而 产生 磁盘 HASH 连接 ， 这 时 候 HASH 连接 性 能 会 严 
重 下 降 。 肉 套 循环 不 需要 消耗 PGA。 

骨 套 循环 每 循环 一 次 ,会 将 驱动 表 连 接 列传 值 给 被 驱动 表 的 连接 列 ， 也 就 是 说 典 套 循环 会 
进行 传 值 。HASH 连接 没有 传 值 的 过 程 。 在 进行 HASH 连接 的 时 候 ， 被 驱动 表 的 连接 列 会 生 
成 HASH 值 , 到 PGA 中 去 探测 驱动 表 所 生成 的 hash table. HASH 连接 的 驱动 表 与 被 驱动 表 的 
连接 列 都 不 需要 创建 索引 。 

OLTP 环境 一 般 是 高 并 发 小 事物 居多 ， 此 类 SQL 返回 结果 很 少 ，SQL МІЗ ІШСЕ 
循环 为 主 ， 因 此 OLTP 环境 SGA 设置 较 大 ，PGA REBRU AIREAN NFE PGA). m 
OLAP 环境 多 数 SQL 都 是 大 规模 的 ETL， 此 类 SQL 返回 结果 集 很 多 ，SQL 执行 计划 通常 以 
HASH 连接 为 主 ， 往 往 要 消耗 大 量 PGA， 所 以 OLAP 系统 PGA 设置 较 大 。 

当 两 表 使 用 外 连接 进行 关联 ， 如 果 执 行 计划 走 的 是 HASH 连接 ， 想 要 更 改 驱 动 表 ， 我 们 
需要 使 用 swap_join_inputs， 而 不 是 leading， 例 如 下 面 SQL. 

кее explain plan for select /*+ use hash(d,e) leading (е) */ 


8 from dept d 
4 left join emp e on d.deptno = e.deptno; 


Explained. 


SQL> select * from table(dbms xplan.display); 
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Plan hash value: 3713469723 


| Та | Operation | Name | Rows | Bytes | Cost ($CPU)| Time 

| 0 | SELECT STATEMENT | | 14 | 812 | 7 (15)| 6010003] 
|* 1 | HASH JOIN OUTER | | 14 | 812 | 7 (15))| 00500501 | 
| 24-1 TABLE ACCESS FULL| DEPT | 4 | 80 | 3 (0) | 00:00:01 

| 3: || TABLE ACCESS FULL| ЕМР | 14 | 532 | 3 (0) 1 00:00:01 


1 — access("D"."DEPTNO"-"E", "DEPTNO" (+)) 
15 rows selected. 
从 执行 计划 中 我 们 可 以 看 到 ，DEPT 5 EMP 是 采用 HASH 连接 ， 这 说 明 use hash(d,e)#E 


效 了 。 执 行 计划 中 ， 豫 动 表 为 DEPT, ЩИ У leading(e)， 但 是 没有 生效 。 现 在 我 们 使 用 
swap join inputs 来 更 改 外 连接 中 HASH 连接 的 驱动 表 。 


SOL» explain plan for select /*+ use hash(d,e) swap join inputs(e) */ 


2 * 

3 from dept d 

4 left join emp e on d.deptno - e.deptno; 
Explained. 


SQL» select * from table(dbms xplan.display); 
PLAN TABLE OUTPUT 


Plan hash value: 3590956717 


| Id | Operation | Name | Rows | Bytes | Cost (%СРО) | Time 

| 0 | SELECT STATEMENT | | 14 | 812 wl Әз 0050001. | 
|* 1] HASH JOIN RIGHT OUTER | | 14 | 812 | q^ X54 [-'00$00$03 | 
| 2. | TABLE ACCESS FULL | ЕМР | 14 | 532. | 3 (0) | 00:00:01 

| 3 | TABLE ACCESS FULL | DEPT | 4 | 80 | 3 (0) 1 00:00:01 


1 = access("D"."DEPTNO"-"E" , "DEPTNO" (4) ) 
15 rows selected. 


从 执行 计划 中 我 们 可 以 看 到 ,使 用 swap_join inputs 更 改 了 外 连接 中 HASH 连接 的 驱动 表 。 
Еж. 怎么 优化 HASH 连接 ? 


回答 : 因为 HASH 连接 需要 将 驱动 表 的 select 列 和 join 列 放 入 РСА 中 ， 所 以 ， 我 们 应 该 
尽量 避免 书写 select * from.... 语 句 , 将 需要 的 列 放 在 select list P, 这样 可 以 减少 驱动 表 对 РСА 
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5.3 排序 合并 连接 ( SORT MERGE JOIN ) 


的 占用 ， 避 免 驱 动 表 被 溢出 到 临时 表 空 间 ， 从 而 提升 查询 性 能 。 如 果 无 法 避免 驱动 表 被 溢出 到 
临时 表 室 间 ,我 们 可 以 将 临时 表 室 间 创 建 在 SSD 上 或 者 RAID 0 E, 加 快 临 时 数据 的 交换 速度 。 

当 PGA 采用 自动 管理 ， 单 个 进程 的 work area 被 限制 在 1G 以 内 ， 如 果 是 PGA 采用 手动 
管理 ， 单 个 进程 的 work area 不 能 超过 2GB 。 如 果 驱 动 表 比 较 大 ， 比 如 驱动 表 有 4GB， 可 以 开 
启 并 行 查询 至 少 parallel(4), 将 表 拆 分 为 至 少 4 £y, 这 样 每 个 并 行进 程 中 的 work area 能 够 容纳 
IGB 数据 ， 从 而 避免 驱动 表 被 溢出 到 临时 表 空 间 。 如 果 驱 动 表 非 常 大 ， 比 如 有 几 十 GB， 这 时 
开启 并 行 HASH 也 无 能 为 力 ， 这 时 ， 应 该 考虑 对 表 进 行 拆 分 ， 在 第 8 章 中 ， 我 们 会 为 大 家 详 
细 介 绍 表 的 拆 分 方法 。 
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前 文 提 到 HASH 连接 主要 用 于 处 理 两 表 等 值 关联 返回 大 量 数据 。 

排序 合并 连接 主要 用 于 处 理 两 表 非 等 值 关 联 , 比如 >, >=，<，<=， 一 ,但 是 不 能 用 于 instr. 
substr, like, regexp like 关联 ，instr、substr、like、regexp_like XXIX ИНЕК ЖЇК 

现 有 如 下 SQL. 


| select * from a,b where a.id>=b.id; 


AX 10 万 条 数据 ，B 表 有 20 万 条 数据 ，A # Ej B 表 的 ID 列 都 是 从 1 开始 每 次 加 1。 

该 SQL 是 非 等 值 连接 ， 因 此 不 能 进行 HASH 连接 。 

假如 该 SQL 走 的 是 嵌 套 循环 ，A 作为 驱动 表 ，B 作为 被 驱动 表 ， 那 么 B 表 会 被 扫描 10 
万 次 。 前 文 提 到 ， 航 套 循环 被 驱动 表 连 接 列 要 包含 在 索引 中 ， 那 么 B X ID 列 需 要 创建 一 个 
索引 ， 枚 套 循环 会 进行 传 值 ， 当 A 表 通 过 ID 列传 值 超过 10 000 的 时 候 ，B 表 通 过 ID 列 的 索 
引 返 回 数据 每 次 都 会 超过 10 000 条 ， 这 个 时 候 会 造成 B 表 大 量 回 表 。 所 以 该 SQL ВЕЕ 
循环 ， 只 能 走 排 序 合并 连接 。 

排序 合并 连接 的 算法 : 两 表 关 联 ， 先 对 两 个 表 根 据 连 接 列 进行 排序 ， 将 较 小 的 表 作 为 驱动 
X* (Oracle 官方 认为 排序 合并 连接 没有 驱动 表 ， 笔 者 认为 是 有 的 )， 然 后 从 驱动 表 中 取出 连接 
列 的 值 ， 到 已 经 排 好 序 的 被 驱动 表 中 匹配 数据 ， 如 果 匹 配 上 数据 ， 就 关联 成 功 。 驱 动 表 返 回 多 
DÍT, 被 驱动 表 就 要 被 匹配 多 少 次 ， 这 个 匹配 的 过 程 类 似 骸 套 循环 ， 但 是 典 套 循环 是 从 被 驱动 
表 的 索引 中 匹配 数据 ， 而 排序 合并 连接 是 在 内 存 中 (PGA 中 的 work area) 匹配 数据 。 

我 们 在 测试 账号 scott 中 运行 如 下 SQL。 


| SQL> select /** gather plan statistics */  e.ename, e.job, 





2 d.dname from emp e, dept d where e.deptno »- d.deptno; 


MM 省 略 输出 结果 . ... . . 
我 们 获取 执行 计划 。 
| SQL» select * from table(dbms xplan.display cursor(null,null, 'ALLSTATS LAST')); 


PLAN TABLE OUTPUT 
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select /*+ gather plan statistics */ е.епапе, e.job, d.dname from 
emp e, dept d where e.deptno »- d.deptno 


Plan hash value: 844388907 


| Id j|Operation | Name |Starts|E-Rows|A-Rows | A-Time  |Buffers| 
| 0 |SELECT STATEMENT | | 11 | 31100:00:00.01| 15| 
| 1 | MERGE JOIN | | 1| 3| 31|00:00:00.01]| 15| 
| 2 | TABLE ACCESS BY INDEX ROWID|DEPT | ІШ 41 4|00:00:00.01| 8| 
| 9. | INDEX FULL 5САМ [РК DEPT| Tl 4| 4|00:00:00.01] 4| 
|* 4| SORT JOIN | | 4| 14| 31|00:00:00.01| 7| 
| 5-1 TABLE ACCESS FULL | EMP | 1! 14| 14|00:00:00.01| НД 


4 - access ("Е" , "РЕРТМО">="р" . "DEPTNO") 
filter("E"."DEPTNO"»-"D"."DEPTNO") 


执行 计划 中 离 MERGE JOIN 关键 字 最 近 的 表 就 是 驱动 表 。 这 里 DEPT 就 是 驱动 表 ，EMP 
就 是 被 驱动 表 。 驱 动 表 DEPT 只 扫描 了 一 次 (Id=2，Starts=1)， 被 驱动 表 EMP 也 只 扫描 了 一 
次 (Id=5,Starts=1)。 

因为 DEPT 走 的 是 INDEX FULL SCAN, INDEX FULL SCAN 返回 的 数据 是 有 序 的 , 所 以 
DEPT 表 就 不 需要 排序 了 。EMP 走 的 是 全 表 扫 描 ， 返回 的 数据 是 无 序 的 ， 所 以 EMP RE PGA 
中 进行 了 排序 。 在 实际 工作 中 ， 我 们 一 定 要 注意 INDEX FULL SCAN 返回 了 多 少 行 数 据 ， 如 
^k INDEX FULL SCAN 返回 的 行 数 太 多 , 应 该 强制 走 全 表 扫 描 , 具体 原因 请 参考 本 书 4.1.8 节 。 

现在 我 们 强制 DEPT 表 走 全 表 扫 描 ， 查 看 执行 计划 。 


SQL> select /*+ full(d) */ 
2 e.ename, e.job, d.dname 
3 from emp e, dept d 
4 where e.deptno >= d.deptno; 


31 rows selected. 


Execution Plan 


Plan hash value: 1407029907 


| Та | Operation | Name | Rows | Bytes | Cost (%CPU)| Time | 
| 0 | SELECT STATEMENT | | 3 | 90 | 8 (25) j) 00:00:01 | 
| 1 | MERGE JOIN | | 3 | 90 | 8 1(25)| 00:00:01 | 
| Ж SORT JOIN | | 4 | 52 | 4  (25)1 00:09:01 
| 3 | TABLE ACCESS FULL| DEPT | 4 | 52 | 3 (0) | 00:00:01 
17°, 445 | SORT JOIN | | 14 | 238 | ta (25) J 500: 00201 1 
| B 1 TABLE ACCESS FULL| EMP | 14 | 238 | 3 (0)| 00:00:01 


Predicate Information (identified by operation id): 
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5.4 币 卡 儿 连 接 ( CARTESIAN JOIN ) 


4 - access ("E"."DEPTNO"»-"D", "DEPTNO") 
filter ("E"."DEPTNO"»-"D"."DEPTNO") 


从 执行 计划 中 我 们 看 到 ，DEPT 走 的 是 全 表 扫 描 ， 因 为 全 表 扫 描 返 回 的 数据 是 无 序 的， 所 
以 DEPT 在 PGA 中 进行 了 排序 。 

如 果 两 表 是 等 值 关 联 , 一 般 不 建议 走 排序 合并 连接 。 因 为 排序 合并 连接 需要 将 两 个 表 放 入 
PGA 中 ， 而 HASH 连接 只 需要 将 驱动 表 放 入 PGA 中 ， 排 序 合并 连接 与 HASH 连接 相 比 ， 需 
要 耗费 更 多 的 PGA。 即 使 排序 合并 连接 中 有 一 个 表 走 的 是 INDEX FULL SCAN， 另 外 一 个 表 
也 需要 放 入 РСА 中 ， 而 这 个 表 往往 是 大 表 ， 如 果 走 HASH 连接 ， 大 表 会 作为 被 驱动 表 ， 是 不 
会 被 放 入 PGA 中 的 。 因 此 ， 两 表 等 值 关 联 ， 要 么 走 NL OREA Eb), HAE HASH GR 
回 数据 量 多 )， 一 般 情况 下 不 要 走 SMJ。 

BE. 怎么 优化 排序 合并 连接 ? 


回答 :如 果 两 表 关 联 是 等 值 关联 , 走 的 是 排序 合并 连接 ,我 们 可 以 将 表 连 接 方 式 改 为 HASH 
连接 。 如 果 两 表 关 联 是 非 等 值 关联 ， 比 如 >，>=，<，<=，<>， 这 时 我 们 应 该 先 从 业务 上 入 手 ， 
尝试 将 非 等 值 关 联 改 写 为 等 值 关联 ， 因 为 非 等 值 关联 返回 的 结果 集 “ 类 似 ” 于 笛 卡 儿 积 ， 当 两 
个 表 都 比较 大 的 时 候 ， 非 等 值 关联 返回 的 数据 量 相 当 “ 克 怖 ”如 果 没 有 办 法 将 非 等 值 关 联 改 
写 为 等 值 关联 , 我 们 可 以 考虑 增加 两 表 的 限制 条 件 , 将 两 个 表 数 据 量 缩 小 ,最 后 可 以 考虑 开启 


并 行 查询 加 快 SQL 执行 速度 。 
Ж 5-1 列举 出 了 3 种 表 连 接 方式 的 主要 区 别 。 
表 5-1 表 连 接 方式 



















被 驱动 表 扫描 次 数 
等 于 驱动 表 返 回 行 数 








两 个 表 关 联 没有 连接 条 件 的 时 候 会 产生 笛 卡 儿 积 ， 这 种 表 连 接 方式 就 叫 笛 卡 儿 连 接 。 
我 们 在 测试 账号 scott 中 运行 如 下 SQL。 


SOL» set autot trace 
SQL» select * from emp, dept; 


56 rows selected. 
Execution Plan 
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маза 85 92v 2 





| 0 | SELECT STATEMENT | | 56 | 3248 | 8 (0)| 00:00:01 | 
| Y АСЕ JOIN CARTESIAN | | 56 | 3248 | 8 (0)| 00:00:01 

| 2 TABLE ACCESS FULL | DEPT | 8-1 80 | 3 (0)1 00:00:01 | 
| 3 | BUFFER SORT | | 14 | 532" | 5 (0)] 00:00:01 | 
| 4 | TABLE ACCESS FULL | EMP | 14 | 532 | d (0)| 00:00:01 | 


执行 计划 中 MERGE JOIN CARTESIAN 就 表示 笛 卡 儿 连 接 。 笛 卡 儿 连接 会 返回 两 个 表 的 
WR. DEPT 有 4 行 数据 ，EMP 有 14 行 数 据 ， 两 个 表 进 行 笛 卡 儿 连接 之 后 会 返回 56 行 数据 。 
笛 卡 儿 连 接 会 对 两 表 中 其 中 一 个 表 进 行 排序 ， 执 行 计划 中 的 BUFFER SORT 就 表示 排序 。 

在 多 表 关 联 的 时 候 ， 两 个 表 没 有 直接 关联 条 件 ， 但 是 优化 器 错误 地 把 某 个 表 返 回 的 Rows 
FA 11r ( 注意 必须 是 工行 )， 这 个 时 候 也 可 能 发 生 笛 卡 儿 连接 。 例 子 如 下 。 


SQL» select * from table(dbms xplan.display()); 


PLAN TABLE OUTPUT 


Plan hash value: 710264295 











| Id | Operation | Name | Rows 
0 | SELECT STATEMENT do 
1 | WINDOW SORT 1 
* || TABLE ACCESS BY INDEX ROWID Е АСТ GUARANTY INFO Н kl 
3 i NESTED LOOPS | ы 
{= „| NESTED LOOPS | | lj 
l 5 | MERGE JOIN CARTESIAN | | 1 
ЫЕ TABLE ACCESS FULL B M BUSINESS CONTRACT | š | 
Tal BUFFER SORT 61507 | 
* 8 | TABLE ACCESS FULL E АСТ GUARANTY RELATIVE Н | 61507 | 
py TABLE ACCESS BY INDEX ROWID| F CONTRACT RELATIVE 121 
* 10 | INDEX UNIQUE 5САМ SYS C0019578 i | 
|* 11 | INDEX RANGE SCAN | SYS C005707 11 


执行 计划 中 14-6 的 表 和 14-8 的 表 就 是 进行 笛 卡 儿 连 接 的。 
在 这 个 执行 计划 中 ， 为 什么 优化 器 会 选择 笛 卡 儿 积 连 接 呢 ? 
因为 1d-6 这 个 表 返 回 的 Rows 被 优化 器 错误 地 估算 为 1 行 ， 优 化 器 认为 1 行 的 表 与 任意 
大 小 的 表 进 行 笛 卡 儿 关 联 , 数据 也 不 会 翻番 , 这 是 安全 的 。 所 以 这 里 优化 器 选择 了 笛 卡 儿 连 接 。 
14-6 这 步 是 全 表 扫 描 ， 而 且 没 过 滤 条 件 〈 因 为 没有 * )， 优 化 器 认为 它 只 返回 1 fT. XX 
请 思考 , 全 表 扫 描 返 回 1 行 并 且 无 过 滤 条 件 ， 这 个 可 能 吗 ? 难道 表 里 面 真 的 就 只 有 1 行 数据 ? 
这 不 符合 常识 。 那 么 显然 是 Id=6 的 表 没 有 收集 统计 信息 ， 导 致 优化 器 默认 地 把 该 表 算 为 1 行 
《当时 数据 库 没 开启 动态 采样 )。 下 面 是 上 述 执行 计划 的 SQL 语句 。 
SELECT b.agmt id, 
corp org, 
cur cd, 
businesstype, 
object no, 
guaranty crsum, 
row number() over(PARTITION BY b.agmt id, b.corp org, c.object no ORDER BY b.a 
gmt id, b.corp org, c.object no) row no 


FROM b m business contract b, -AR 
dwf.f_contract_relative с, -- 合 同 关 联 表 


о о o b D 


5.4 ЕЛЖ # ( CARTESIAN JOIN ) 








WHERE b.corp_org = c.corp_org 
AND b.agmt id = c.contract seqno -- 业 务 合同 号 
AND c.object type = 'GuarantyContract' 
AND r.start dt <= DATE '2012-09-17' /* 当 天 日 期 */ 
AND r.end dt > DATE '2012-09-17' /* 当 天 日 期 */ 
AND c.contract seqno = r.object no -- 业 务 合同 号 
AND c.object_no = r.guaranty_no -- 担 保 合同 编号 
AND c.corp org = r.corp org -- 企 业 法 人 编码 
AND r.object type = 'BusinessContract' 
AND r.agmt id = g.agmt id -- 担 保 物 编号 
AND r.corp org = g.corp org -= 企业 法 人 编码 
AND g.start dt <= DATE '2012-09-17' /* 当 天 日 期 */ 
AND g.end dt > DATE '2012-09-17' /* 当 天 日 期 */ 
AND g.guarantytype = '020010' =-- 质 押 存 款 


执行 计划 中 进行 笛 卡 儿 关 联 的 表 就 是 bp fi r, ZE SQL 语句 中 b 和 + 没有 直接 关联 条 件 。 

如 果 两 个 表 有 直接 关联 条 件 ， 无 法 控制 两 个 表 进 行 笛 卡 儿 连 接 。 

如 果 两 个 表 没有 直接 关联 条 件 , 我 们 在 编写 SQL 的 时 候 将 两 个 表 依 次 放 在 from 后 面 并 且 
添加 HINT: ordered， 就 可 以 使 两 个 表 进 行 笛 卡 儿 积 关联 。 


SQL> select /*+ ordered */ 
2 a.ename, a.sal, a.deptno, b.dname, c.grade 
3 from dept b, salgrade c, emp a 
4 where a.deptno = b.deptno 
Š and a.sal between c.losal and c.hisal; 


14 rows selected. 
Execution Plan 


Plan hash value: 2197699399 





Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time 

0 | SELECT STATEMENT | | X | 65 | 12 (9)| 00:00:01 

|l* 1]| HASH JOIN | | 1 ] 65 | 12 (9) | 00:00:01 

І 2| MERGE JOIN CARTESIAN| l 20 | 1040 | 8 (0)| 00:00:01 | 
С | TABLE ACCESS FULL | DEPT | 4 | 52 | 3 (0) | 00:00:01 
4 | BUFFER SORT | | Š. | 195. | 5 (0)| 00:00:01 
& 1 TABLE ACCESS FULL | SALGRADE | 5 | 195 | 1 (0)| 00:00:01 
6 | TABLE ACCESS FULL | EMP | 14 | 182 | 3 (0)| 00:00:01 


1 = access ("A"."DEPTNO"-"B","DEPTNO") 
filter("A"."SAL"»-"C"."IOSAL" AND "A"."SAL"«-"C"."HISAL") 


在 SQL 语句 中 ，DEPT 与 SALGRADE 没有 直接 关联 条 件 ，HINT: ordered 表示 根据 SQL 
语句 中 from 后 面 表 的 顺序 依次 关联 。 因 为 DEPT 与 SALGRADE 没有 直接 关联 条 件 ,而且 SQL 
语句 中 添加 了 HINT: ordered, HA SQL 语句 中 两 个 表 是 依次 放 在 from 后 面 的 ， 所 以 DEPT 
与 SALGRADE Я ВМТ ЕЛЕ. 





98 


思考 : 当 执 行 计划 中 有 笛 卡 儿 连 接应 该 怎么 优化 呢 ? 


首先 应 该 检查 表 是 否 有 关联 条 件 , 如 果 表 没有 关联 条 件 , 那么 应 该 询问 开发 与 业务 人 员 为 
何 表 没有 关联 条 件 ， 是 否 为 满足 业务 需求 而 故意 不 写 关 联 条 件 。 

其 次 应 该 检查 离 笛 卡 儿 连 接 最 近 的 表 是 否 真 的 返回 1 行 数据 ， 如 果 返 回 行 数 真 的 只 有 1 
行 ， 那 么 走 笛 卡 儿 连 接 是 没有 问题 的 ， 如 果 返 回 行 数 超过 1 行 ， 那 就 需要 检查 为 什么 Rows 会 
估算 错误 ， 同 时 要 纠正 错误 的 Rows。 纠 正 错误 的 Rows 之 后 ， 优 化 器 就 不 会 走 笛 卡 儿 连 接 了 。 

我 们 可 以 使 用 HINT /*+ opt param('_optimizer mjc_enabled', 'false') */ ЖЕДЕ. 


D У w. t 
3 É i 2 5 е ГІ ҮТ ШІЛ Бест 
x = НШІ Toe me ү 
EE: | FE n | L3 
? - " ч > ‹ e en 


当 一 个 子 查 询 介 于 select 与 from 之 间 ， 这 种 子 查 询 就 叫 标量 子 查询 ， 例 子 如 下 。 


| select e.ename, 





e.sal, 


(select d.dname from dept d where d.deptno = e.deptno) dname 
from emp e; 


我 们 在 测试 账号 scott 中 运行 如 下 SQL. 


SQL> select /*+ gather plan statistics */ e.ename, 





e. sal, 
3 (select d.dname from dept d where d.deptno = e.deptno) dname 
4 from emp e; 
ОЛКЕ 省 略 输出 结果 . . . .. . 


SQL» select * from table(dbms xplan.display cursor(null,null,'ALLSTATS LAST')); 


PLAN TABLE OUTPUT 


select /** gather plan statistics */ e.ename, e.sal, 
(select d.dname from dept d where d.deptno - e.deptno) dname from emp e 


Plan hash value: 2981343222 


| Id [Operation | Name |Starts|E-Rows |A-Rows | A-Time | Buffers | 
| 0 [SELECT STATEMENT | | 1| | 14|00:00:00.01| 8 
| 1 | TABLE ACCESS BY INDEX ROWID|DEPT | 3I 1| 3|00:00:00.01| 5 
|% 2 | INDEX UNIQUE SCAN [РК DEPT| 3| 11 3100:00:00.01| 2 
| 3 | TABLE ACCESS FULL | EMP | 1| 14| 14|00:00:00.01| 8 


2.2 access ("D" , "РЕРТМО"= В) 


标量 子 查 询 类 似 一 个 天 然 的 嵌 套 循环 ， 而 且 驱 动 表 固 定 为 主 表 。 大 家 是 否 还 记得 : ЇКА ЇН 
环 被 驱动 表 的 连接 列 必须 包含 在 索引 中 。 同 理 , 标量 子 查 询 中 子 查 询 的 表 连 接 列 也 必须 包含 在 


5.5 标量 子 查询 ( SCALAR SUBQUERY ) 


索引 中 。 主 表 EMP 通过 连接 列 (DEPTNO) 传 值 给 子 查 询 中 的 表 (DEPT)， 执 行 计划 中 :B1 
就 表示 传 值 ， 这 个 传 值 过 程 一 共 进行 了 3 次 ， 因 为 主 表 (EMP) 的 连接 列 (DEPTNO) 基数 等 
T 


SOL» select count (distinct deptno) from emp; 


COUNT (DISTINCTDEPTNO) 


我 们 建议 在 工作 中 , 尽量 避免 使 用 标量 子 查询 ， 假 如 主 表 返 回 大 量 数据 ,， 主 表 的 连接 列 基 
数 很 高 ， 那 么 子 查询 中 的 表 会 被 多 次 扫描 ， 从 而 严重 影响 SQL 性 能 。 如 果 主 表 数 据 量 小 ， 或 
者 主 表 的 连接 列 基数 很 低 , 那么 这 个 时 候 我 们 也 可 以 使 用 标量 子 查询 , 但 是 记得 要 给 子 查 询 中 
表 的 连接 列 建立 索引 。 

当 SQL 里 面 有 标量 子 查 询 ， 我 们 可 以 将 标量 子 碍 询 等 价 改写 为 外 连接 ， 从 而 使 它们 可 以 
进行 HASH 连接 。 为 什么 要 将 标量 子 查 询 改 写 为 外 连接 而 不 是 内 连接 呢 ? 因为 标量 子 查 询 是 
一 个 传 值 的 过 程 ， 如 果 主 表 传 值 给 子 查 询 ， 子 查询 没有 查询 到 数据 ， 这 个 时 候 会 显示 NULL. 
如 果 将 标量 子 查 询 改 写 为 内 连接 ， 会 丢失 没有 关联 上 的 数据 。 

现 有 如 下 标量 子 查询 。 


SOL» select d.dname, 
2 d.lec;, 
3 (select max(e.sal) from emp e where e.deptno - d.deptno) max sal 
4 from dept d; 


DNAME LOC MAX SAL 
ACCOUNTING NEW YORK 5000 
RESEARCH DALLAS 3000 
SALES CHICAGO 2850 
OPERATIONS BOSTON -—--NULL 


我 们 可 以 将 其 等 价 改写 为 外 连接 : 


SQL> select d.dname, d.loc, e.max_sal 


2 from dept d 

3 left join (select max(sal) max_sal, 

4 deptno 

5 from emp 

6 group by deptno)e 

7 on d.deptno = e.deptno; 
DNAME LOC MAX SAL 
ACCOUNTING NEW YORK 5000 
RESEARCH DALLAS 3000 
SALES CHICAGO 2850 
OPERATIONS BOSTON ---NULL 


当然 了 ， 如 果 主 表 的 连接 列 是 外 键 ， 而 子 查询 的 连接 列 是 主键 ,我们 就 没 必要 改写 为 外 连 
接 了 ， 因 为 外 键 不 可 能 存 NULL 值 ， 可 以 直接 改写 为 内 连接 。 例 如 本 书 中 所 用 的 标量 子 查询 
示例 就 可 以 改写 为 内 连接 ， 因 为 DEPT 与 EMP 有 主 外 键 关系 。 
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“yumay aya: outta ila Gia 


from emp e 


select e.ename, e.sal, d.dname 
inner join dept d on e.deptno = d.deptno; 


在 Oracle12c 中 ， 简 单 的 标量 子 查 询 会 被 优化 器 等 价 改写 为 外 连接 。 


两 表 关 联 只 返回 一 个 表 的 数据 就 叫 半 连接 。 半 连接 一 般 就 是 指 的 in 和 exists. 在 SQL Ж 
化 实战 中 ， 半 连接 的 优化 是 最 为 复杂 的 。 
561 半 连 接 等 价 改写 


in 和 exists 一 般 情 况 下 都 可 以 进行 等 价 改写 。 
半 连 接 in 的 写法 如 下 。 


SQL» select * from dept where deptno ín (select deptno from emp); 





DEPTNO DNAME LOC 


10 ACCOUNTING NEW YORK 
20 RESEARCH DALLAS 
30 SALES CHICAGO 


半 连 接 exists 的 写法 如 下 。 


SQL» select * from dept where exists (select null from emp where dept.deptno-emp.dept 
no); 


DEPTNO DNAME LOC 
10 ACCOUNTING NEW YORK 
20 RESEARCH DALLAS 
30 SALES CHICAGO 


in 和 exists 有 时 候 也 可 以 等 价 地 改写 为 内 连接 , 例如 ,上面 查询 语句 可 以 改写 为 如 下 写法 。 


SOL» select d.* 
2 from dept d, (select deptno from emp group by deptno) e 
3 where d.deptno = e.deptno; 


DEPTNO DNAME LOC 
10 ACCOUNTING NEW YORK 
20 RESEARCH DALLAS 
30 SALES CHICAGO 


ЖЕ: 上 面 内 连接 的 写法 性 能 没有 半 连 接 写法 性 能 高 ， 因 为 多 了 GROUP BY 去 重 操作 。 

在 将 半 连 接 改 写 为 内 连接 的 时 候 ， 我 们 要 注意 主 表 与 子 表 〈 子 查询 中 的 表 ) 的 关系 。 这 里 
DEPT 与 EMP 是 1: n 关系。 在 半 连 接 的 写法 中 ,返回 的 是 DEPT 表 的 数据 ， 也 就 是 说 返回 的 
数据 是 属于 1 的 关系 。 然 而 在 使 用 内 连接 的 写法 中 , 由 于 DEPT 5 EMP 是 1 : n 关系 ， 两 表 关 
联 之 后 会 返回 n (有 重复 数据 )， 所 以 我 们 需要 加 上 GROUP BY 去 掉 重 复数 据 。 


56 ОЕ ( SEMI JOIN ) 


如 果 半 连接 中 主 表 属于 1 的 关系 ， 子 表 ( 子 查询 中 的 表 ) 属于 n 的 关系 , 我 们 在 改写 为 内 
连接 的 时 候 ， 需 要 加 上 GROUP BY 去 重 。 注 意 : 这 个 时 候 半 连接 性 能 高 于 内 连接 。 

如 果 半 连接 中 主 表 属于 mn 的 关系 ， 子 表 〈 子 查询 中 的 表 ) 属于 1 的 关系 ， 我 们 在 改写 为 内 
连接 的 时 候 ， 就 不 需要 去 重 了 。 注 意 ; 这 个 时 候 半 连接 与 内 连接 性 能 一 样 。 

如 果 半 连接 中 主 表 属于 n 的 关系 ， 子 表 〈 子 查询 中 的 表 ) 也 属于 nm 的 关系 ,这 时 我 们 可 以 
先 对 子 查询 去 重 ， 将 子 表 转 换 为 1 的 关系 ， 然 后 再 关联 ， 千 万 不 能 先 关 联 再 去 重 。 

作者 的 个 人 技术 博客 上 记载 了 一 篇 半 连 接 被 优化 器 改写 为 内 连接 而 导致 查询 变 慢 的 经 典 
案例 ,如果 大 家 有 兴趣 可 以 阅读 参考 : http://blog.csdn.net/robinson1988/article/details/51148332。 


5.6.2 控制 半 连 接 执行 计划 
我 们 先 来 查看 示例 SQL 的 原始 执行 计划 。 


SQL» select * from dept where deptno in (select deptno from emp); 


Execution Plan 


| Id | Operation | Name | Rows | Bytes | Cost (%СРО) | Time 
| 0 | SELECT STATEMENT | | З | 69 | 6 (17) | 00:00:01 
| 1 | MERGE JOIN SEMI | | 3. | 69 | 6 (17) 00:00:01 | 
E {| TABLE ACCESS BY INDEX ROWID| DEPT | 4 | 80 | 2 (0)| 00:00:01 | 
[S INDEX FULL SCAN | PK DEPT | 4 | | % (0) | 00:00:01 
|% 4-| SORT UNIQUE | | 14 | 42 | 4 (25) | 00:00201 | 
[ 341 TABLE ACCESS FULL | ЕМР | 14 | 42 | 3 (0)| 00:00:01 | 
Predicate Information (identified by operation id): 
4 - access ("DEPTNO"="DEPTNO") 
filter ("DEPTNO"="DEPTNO") 
执行 计划 中 DEPT 与 EMP 是 采用 排序 合并 连接 进行 关联 的 。 
我 们 现在 让 DEPT 与 EMP 进行 风 套 循环 连接 ， 同 时 让 DEPT 当 驱 动 表 。 

SQL» select /*+ use nl(emp@a,dept) leading(dept) */ 

2 * 

3 from dept 

4 where deptno in (select Й qb name(a) */ deptno from emp); 
Execution Plan 
Plan hash value: 2645846736 
| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time | 
| 0 | SELECT STATEMENT | | 3 j 69 | 8 (0y | 00:00:01 | 


101 





102 
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| 1 | NESTED LOOPS SÉME | | 3. | 69 | 8 (0) | 00:00:01 | 
| 271 TABLE ACCESS FULL| DEPT | 4 | 80 | 3 (0) | 00:00:01 
50631 TABLE ACCESS FULL| ЕМР | Sul 27. | 1 (0)| 00:00:01 


3 = filter("DEPTNO"-"DEPTNO") 


有 读者 可 能 会 好 奇 ， 为 何不 写 HINT /*+ use nl(deptemp) leading(dept) */? 

因为 在 Oracle 数据 库 中 ， 每 个 子 查 询 都 会 自动 生成 一 个 查询 块 〈query block), TAWE 
面 的 表 会 自动 地 被 优化 器 取 别 名 。 这 里 from 后 面 的 表 只 有 DEPT, 而 EMP 在 子 碍 询 中 ，HINT 
写成 use nl(dept;emp) 87 СВО 无 法 识别 EMP， 为 了 让 СВО 能 识别 到 EMP， 在 子 查询 中 
添加 了 qb name 这 个 HINT， 给 子 查 询 取 别名 为 a， 再 在 主 查 询 中 使 用 use _nl(emp@a,dept), 
就 能 使 两 表 进行 艇 套 循环 关联 。 

如 果 不 想 使 用 qb_name 这 个 HINT， 我 们 也 可 以 参考 如 下 操作 。 


SQL> explain plan for select * from dept where deptno in (select deptno from emp); 


















Explained. 


SQL» select * from table(dbms xplan.display(null, null, 'advanced -projection -outlin 
e -predicate')); 


PLAN TABLE OUTPUT 


Plan hash value: 1090737117 


| Id | Operation | Name | Rows | Bytes | Cost (%СРУ) |Тіпе 

| 0 | SELECT STATEMENT | | 3. 1] 69 | 6 (17)|00:00:01| 
| 1 | MERGE JOIN SEMI | | 3 l 69 | 6 (17)|00:00:01| 
rg TABLE ACCESS BY INDEX ROWID| DEPT | 4 | 80 | 2 (0) 100:00:01| 
je 3) INDEX FULL 5САМ | PK DEPT | 4 | | 1 (0) 100:00:01| 
| 4 | SORT UNIQUE | | 14 | 42 | 4 (25) [00:00:04] 
І 2! TABLE ACCESS FULL | BMP | 14 | 42 | 3 (0) 100:00:02 | 


Query Block Мате / Object Alias (identified ру operation іа): 


SEL$5DA710D3 

SEL$5DA710D3 / DEPTGSELS1 
SEL$5DA710D3 / DEPT@SEL$1 
SEL$5DA710D3 / EMPGOSELSZ 


І 


Q Q N = 
I 





20 rows selected. 


SQL» select /*+ use nl(dept,&mpüsels. 
2 ж 
3 from dept P. 
4 where deptno in (select deptno from emp); 


D 





Execution Plan 


5.6 ОЕ ( SEMI JOIN ) 


Plan hash value: 2645846736 


| Та | Operation | Name | Rows | Bytes | Cost (%СРӘ) | Time 

| 0 | SELECT STATEMENT | | ар | 69 | 8 (0) | 00:00:01 | 
| 1 | NESTED LOOPS SEMI | | 3. 1] 69 | 8 (0) 1 00:00:01 | 
| Al TABLE ACCESS FULL| DEPT | 4 | 80 | 3 (0)| 00:00:01 
pe ^з TABLE ACCESS FULL| EMP | 9 | 23. || 1 (9) | 00:00:01 


Predicate Information (identified by operation id): 


3 - filter("DEPTNO"-"DEPTNO") 


现在 我 们 让 DEPT 与 EMP 进行 HASH 连接 ， 同 时 让 EMP 作为 驱动 表 。 


SQL» select /%% nse hash(dept,empüsel$2) leading(empésel$2) */ 
2 * 
3 from dept 
4 where deptno in (select deptno from emp); 


Execution Plan 


Plan hash value: 300394613 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time 

| 0 | SELECT STATEMENT | | = J 69 | 8 Хез 00900701. | 
[* 2 | RASH JOIN | | ЗГ | 69 | 8 (25) СІНЕ 1 
| 2 || SORT UNIQUE | | 14 | 42 | 3 (0)] 00%00:02 | 
| 2 TABLE ACCESS FULL| EMP | 14 | 42 | 3 (0)] 00:00:01 

| 4 | TABLE ACCESS FULL | DEPT | 4 | 80 | 3 (0) 09:00:04 


Predicate Information (identified by operation id): 


І - access ("DEPTNO"-"DEPTNO") 


让 EMP 表 作 为 驱动 表 之 后 ，CBO 先 对 EMP 进行 了 去 重 (SORT UNIQUE) 操作 ， 这 里 


CBO 其 实 对 该 SQL 进行 了 等 价 改写 , 将 半 连 接 等 价 改写 为 内 连接 (因为 执行 计划 中 没有 SEMI 
关键 字 )， 在 改写 的 过 程 中 ， 因 为 EMP 属于 N 的 关系 ， 所 以 对 EMP 进行 了 去 重 。 


563 ”读者 思考 


现 有 如 下 SQL。 


select * from a where a.id in (select id from b); 


假设 a 有 1000 77, b 有 100 行 ， 请 问 如 何 优 化 该 SQL? 
假设 a 有 10017, b 有 1000 万 ， 请 问 如 何 优 化 该 SQL? 
假设 a 有 100 万 ，b 1000 万 ， 请 问 如 何 优 化 该 SQL? 
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两 表 关 联 只 返回 主 表 的 数据 ， 而 且 只 返回 主 表 与 子 表 没 关联 上 的 数据 ,这 种 连接 就 叫 反 连 
接 。 反 连接 一 般 就 是 指 的 not in 和 not exists。 
5.7.1 反 连 接 等 价 改写 


not in 与 not exists 一 般 情况 下 也 可 以 进行 等 价 改写 。 
not in 的 写法 如 下 。 


SQL» select * from dept where deptno Hotin 





(select deptno from emp); 


DEPTNO DNAME LOC 
40 OPERATIONS BOSTON 
not exists 的 写法 如 下 。 


SQL> select * 
2 from dept 





3 where Hot 18Е8 (select null from emp where dept.deptno = emp.deptno); 
DEPTNO DNAME LOC 
40 OPERATIONS BOSTON 


需要 注意 的 是 ，not іп 里 面 如 果 有 null， 整 个 查询 会 返回 空 ， 而 in 里 面 有 null， 查 询 不 受 
null 影响 ， 例 子 如 下 。 
SOL» select * from dept where deptno not in (10,null); 
no rows selected 
SQL» select * from dept where deptno in (10,null); 
DEPTNO DNAME LOC 


10 ACCOUNTING NEW YORK 


所 以 在 将 not exists 等 价 改 写 为 not in 的 时 候 ， 要 注意 null。 一 般 情 况 下 ， 如 果 反 连接 采用 
not in 写法 ， 我 们 需要 在 where 条 件 中 剔除 nullo 


select * 
from dept 


where deptno not in (select deptno from emp WFP 


not in 与 not exists 除了 可 以 相互 等 价 改写 以 外 ， 还 可 以 等 价 地 改写 为 外 连接 ， 例如 ， 上 面 
查询 可 以 等 价 改写 为 如 下 写法 。 


SQL> select d.* 
2 from dept d 
3 left join emp е on d.deptno = e.deptno 
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57 反 连 接 (ANTI JOIN ) 


4 where e.deptno is null; 


DEPTNO DNAME LOC 


40 OPERATIONS BOSTON 


为 什么 反 连 接 可 以 改写 为 “外 连接 + 子 表 连 接 条 件 is null” ? 我 们 再 来 回顾 一 下 反 连 接 定 
X: 两 表 关联 只 返回 主 表 的 数据 , 而 且 只 返回 主 表 与 子 表 没有 关联 上 的 数据 。 根据 反 连 接 定义 ， 
翻译 为 标准 SQL 写法 就 是 “外 连接 + 子 表 连接 条 件 is null”。 与 半 连 接 改写 为 内 连接 不 同 的 是 ， 
反 连 接 改写 为 外 连接 不 需要 考虑 两 表 之 间 的 关系 。 


5.7.2 ”控制 反 连 接 执行 计划 
我 们 先 来 查看 示例 SQL 的 原始 执行 计划 。 


SQL» select * from dept where deptno not in (select deptno from emp); 


Execution Plan 


Plan hash value: 2230682264 


| Id | Operation | Name | Rows | Bytes | Cost($CPU)|Time 

| 0 | SELECT STATEMENT | | 1 | 23 | 6 (17)100:00:011| 
| 1 | MERGE JOIN ANTI МА | | k. ll Фу 6 (17)100:00:01| 
L 22 4 SORT JOIN | | 4 | 80 | 2 (0) 100:00:01| 
224 TABLE ACCESS BY INDEX ROWID| DEPT | 4 | 80 | 2 (0)100:00:01] 
| 4| INDEX FULL SCAN | PK DEPT | 4 | | 1 (0) 100:00:01| 
|% 5 | SORT UNIQUE | | 14 | 42 | 4 (25) |00:00:01| 
І 61 TABLE ACCESS FULL | EMP | 14 | 42 | 3 (0)100:00:01| 


5 - access ("DEPTNO"-"DEPTNO") 
filter("DEPTNO"-"DEPTNO") 


原始 执行 计划 中 DEPT 5 EMP 是 采用 排序 合并 连接 进行 关联 的 。 
我 们 现在 让 DEPT 与 EMP 使 用 嵌 套 循环 进行 关联 ， 台 区 动 表 
Tni (deptrenptaj */ * 








SQL» select /*+ use. 
2 from dept 
3 where deptno not in (select /*+ 8Б папе(а) */ 
4 deptno 
5 from emp); 





Execution Plan 


Plan hash value: 1831344308 


| 0 | SELECT STATEMENT | | die 23 | 11 (0)| 00:00:01 
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|% 1 | Еа | | | | | | 
| 27) NESTED LOOPS ANTI 5МА| | | 23. | DI (28)| 00:00:01 
| 3271 TABLE ACCESS FULL | DEPT | 4 | 80 | 3 (0) 1 00:00:01 
(% 4 | TABLE ACCESS FULL | EMP | 9 | 27 | s (0) | 00:00:01 
|Ж 51 TABLE ACCESS FULL | EMP | 1 | S | 3 (0)]-00:00:01 | 


Predicate Information (identified by operation id): 


1 - filter( NOT EXISTS (SELECT /*+ QB NAME ("A") */ 0 FROM "ЕМР" 


"EMP" WHERE "DEPTNO" IS NULL)) 
4 - filter("DEPTNO"-"DEPTNO") 
5 - filter("DEPTNO" IS NULL) 


执行 计划 居然 变 成 了 FILTER, 我 们 指定 的 HINT 被 CBO 忽略 了 。 这 究竟 是 什么 原因 呢 ? 
注意 观察 FILTER 对 应 的 谓词 部 分 我 们 就 能 发 现 原因 。 因 为 子 表 EMP 的 连接 列 DEPTNO 没有 
排除 存在 null 的 情况 , 所 以 СВО 选择 了 FILTER. 现在 我 们 给 子 查 询 加 上 语句 where deptno 
is not null 再 看 一 下 执行 计划 。 


SOL> select /*+ изе ml(dept,emp@a) */ + 
2 from dept 
3 where deptno not in (select /*+ gb name(a) */ 
4 deptno 
5 from emp Where deptno is not null); 


Execution Plan 


Plan hash value: 1522491139 


0 | SELECT STATEMENT | | | | 8 (0y] 00:00:01 | 
1 | NESTED LOOPS ANTI | | | 23» | 8 (0) | 00:00:01 | 
2 || TABLE ACCESS FULL| DEPT | | | 3 (0)! 00:00:01 | 
3 | TABLE ACCESS FULL| EMP | | | 1 (0) 1 00:00:01 | 


3 - filter("DEPTNO" IS NOT NULL AND "DEPTNO"-"DEPTNO") 


现在 我 们 将 not in 改写 为 not exists, П E HINT， 再 查看 执行 计划 。 


SQL» select /*4 БББ empéa) */ > 
2 from dept 
3 where not exists 


4 (select /*« gnane (a) */ null from emp where emp.deptno = dept.deptno); 


Execution Plan 
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| 0 | SELECT STATEMENT | | i 1 23 ] 8 (0)| 00:00:01 | 
| 1 | NESTED LOOPS ANTI | | 191 23-1 8 (0) | 00:00:01 | 
| 2 | TABLE ACCESS FULL| DEPT | 4 | 80 | 3 00) 1 00:00:01 
|54327) TABLE ACCESS FULL| ЕМР | 9-1 ӚЗ 7) 1 (0) | 00:00:01 


3 = filter("EMP"."DEPTNO"-"DEPT","DEPTNO") 


在 执行 计划 中 ，DEPT а UA, EM 是 髓 套 循环 的 被 驱动 表 。 现 在 我 们 让 
DEPT 与 EMP 还 进行 SORTEO 连接 ， 但 5 EMP 作为 驱动 表 。 





SQL» select /*+ 056 ipga) */ * 
2 from dept 
3 where not exists 


4 (select /*+ ЧЫ name(a) */ null from emp where emp.deptno = dept.deptno); 


Execution Plan 


Plan hash value: 1522491139 





| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time 

| 0 | SELECT STATEMENT | | hi 23 | 8 (0) | 00:00:01 | 
| 1 | RNESTED LOOPS ANTI | gj 23 | 8 (0)| 00:00:01 | 
| 2f i TABLE ACCESS FULL| DEPT | 4 | 80 | 3 (0)| 00:00:01 
| “42! TABLE ACCESS FULL| EMP | 9 | е. 1 (0) | 00:00:01 


Predicate Information (identified by operation id): 


3 - filter("EMP",."DEPTNO"-"DEPT". "DEPTNO") 


注意 观察 执行 计划 ， 虽 然 我 们 使 用 了 leading(emp@a) 强 制 让 EMP 作为 驱动 表 ， 但 是 执行 
计划 中 驱动 表 还 是 DEPT. 这 是 为 什么 呢 ? 因为 反 连 接 等 价 于 “外 连接 + 子 表 连 接 条 件 is null”, 
大 家 是 否 还 记得 : 当 两 表 关 联 是 外 连接 ， 使 用 嵌 套 循环 进行 关联 的 时 候 无 法 更 改 驱 动 表 ， 驱 动 
表 会 被 固定 为 主 表 。 

现在 我 们 让 DEPT 与 EMP HASH Шалы EMP 作为 驱动 表 。 


SQL» select /*+ Шве hash(dej 
2 from dept 
3 where not exists 
4 (select /x+ ДБ папе (а) */ null from emp where emp.deptno = dept.deptno); 





Execution Plan 


Plan hash value: 474461924 


| 0 | SELECT STATEMENT | | ds. il 23: | 7: "Бу 00200:01 | 


107 








1 | HASH JO 1 | 1-5 23. | T AASIN 00:00:01 | 
| 2.4] ТАВІЕ ACCESS FULL| DEPT | 4 | 80 | 3 (0)| 00:00:01 | 
| 3.1 TABLE ACCESS FULL| EMP | 14 | 42 | 3 (0) 1 00:00:01 


1 — access ("EMP"."DEPTNO"-"DEPT" , "DEPTNO") 


虽然 DEPT 与 EMP 采用 的 是 HASH 连接 ,但 是 驱动 表 还 是 DEPT.。 为 什么 leading(emp@a) 
失效 了 呢 ? 因为 两 表 关 联 如 果 是 外 连接 ， 要 改变 HASH 连接 的 驱动 表 必 须 使 用 swap join inputs. 
现在 我 们 使 用 swap join : HASH Es s du 


SQL» select /*+ use has 
2 from dept 
3 where not exists 
4 (select /*4 gb 








a) */ null from emp where emp.deptno = dept.deptno); 


Execution Plan 





L 
一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 { 
Plan hash value: 152508289 | 
| Та | Operation | Name | Rows | Bytes | Cost ($CPU)| Time | | 
| D | ` STATEMENT | | L: "| 23 | 7 (15)| 00:00:01 | I 
pi E JOIN RIGHT ANTI | 1 | 23.1 7 (5/1 00:00501 | | 
| 211 TABLE ACCESS FULL | EMP | 14 | 42 | 3 (0) 1 00:00:01 
| 3 | TABLE ACCESS FULL | DEPT | 4 | 80 | 3 (0)| 00:00:01 | 


1 = access("EMP"."DEPTNO"-"DEPT" , "DEPTNO") 


57.3 读者 思考 
现 有 如 下 SQL。 


| select * from a where a.id not in (select id from b where id is not null); 


假设 a 有 1000 万 条 ，b 有 1 000 条， 请 问 如 何 优化 该 SQL? 
假设 a 有 1000 条 ，b 1 000 万 条 ， 请 问 如 何 优化 该 SQL? 
假设 a 有 100 万 条 ，b 有 1 000 万 条 ， 请 问 如 何 优化 该 SQL? 


如 果子 查询 (in/exists/not in/not exists) 没 能 展开 (unnest), 在 执行 计划 中 就 会 产生 FILTER, 
FILTER ИИА, FILTER 的 算法 与 标量 子 查询 一 模 一 样 。 
现 有 如 下 SQL 以 及 其 执行 计划 。 
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5.8 FILTER 


SQL> select ename, deptno 









2 from emp 

3 where exists (select deptno 

4 from dept 

5 where emp.deptno = dept.deptno 
6 and d 'RESEARCH' 

7 ап р); 


Plan hash value: 3414630506 





| Id | Operation | Name | Rows | Bytes | Cost($CPU)|Time | 
| 0 | SELECT STATEMENT | | 5 | 45 | 6 (0) 100:00:011 
= 1 | ШШШ | | | | 

D. xw TABLE ACCESS FULL | EMP | 14 | 126 | 3 (0) 00:00:01} 
| [ksi WA | COUNT STOPKEY | | | | | | 
|* 3 | TABLE ACCESS BY INDEX ROWID| DEPT | L «| 13.) 1 (0) 00:00:01 
К. INDEX UNIQUE SCAN | ВК DEPT | As WI | 0 (0)100:00:01] 


1 = filter 





Š (SELECT 0 FROM "DEPT" "DEPT" WHERE ROWNUM-1 AND 
"D ."ЮЕРТМО"= ВІ AND "DNAME"-'RESEARCH!)) 

3 - filter (ROWNUM-1) 
4 = filter("DNAME"-'RESEARCH') 
5 - access ("DEPT"."DEPTNO"-EBI) 


执行 计划 中 ，Id=1 就 是 FILTER. Е FILTER 所 对 应 的 谓词 信息 ，FILTER 对 应 的 请 
词 中 包含 有 )。 运 用 光标 移动 大 法 我 们 可 以 知道 FILTER 下 面 有 两 个 儿子 
(14-2, 14-3). 

现在 我 们 来 看 一 下 上 面 SQL 带 有 A-Time 的 执行 计划 。 


SQL> alter session set statistics level=all; 











Session altered. 


SQL> select ename, deptno 


2 from emp 

3 where exists (select deptno 

4 from dept 

5 where emp.deptno = dept.deptno 
6 and dname = 'RESEARCH' 

7 and rownum = 1); 

: ENAME DEPTNO 
SMITH 20 
JONES 20 
SCOTT 20 
ADAMS 20 
FORD 20 


SQL» select * from table(dbms xplan.display cursor (null,null, 'ALLSTATS LAST] Yg 
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PLAN TABLE OUTPUT 


select ename, deptno from emp where exists (select deptno 
from dept where emp.deptno - dept.deptno and dname 
= 'RESEARCH' and rownum = 1) 


Plan hash value: 3414630506 


| Id | Operation | Name | Starts | E-Rows | A-Rows | 
| 0 | SELECT STATEMENT | | УД | 5 | 
|* 3 | FELTER | | del | 5 | 
| 21 TABLE ACCESS FULL | EMP | 1 | 14 | 14 | 
|” | COUNT STOPKEY | | 8 | | T | 
е oux TABLE ACCESS BY INDEX ROWID| DEPT | É | d Í 1 

ЦИБ] INDEX UNIQUE SCAN | PK DEPT | 8 | 14”) 3 


- filter( IS МОТ NULL) 
- filter(ROWNUM-1) 

- filter ("DNAME"-'RESEARCH') 
- ассевз("БЕРТ"."рЕРТМО"- В1) 


为 了 方便 排版 ， 执 行 计划 中 省 略 了 部 分 内 容 。Id=2 以 及 Id=3 都 是 FILTER 的 儿子 。Id=2 
靠近 FILTER, 我 们 可 以 把 Id=2 理解 为 FILTER 的 驱动 表 ; Id=3 离 FILTER 比较 远 , 可 以 把 Id-3 
理解 为 FILTER 的 被 驱动 表 。 驱 动 表 EMP 只 扫描 了 一 次 〈Id=2，Starts=1)， 被 驱动 表 被 扫描 
了 3 次 〈Id=3，Starts=3 )。 

FILTER 的 算法 与 标量 子 查 询 一 模 一 样 ， 驱 动 表 都 是 固定 的 (固定 为 主 表 )， 不 可 更 改 。 

从 执行 计划 中 我 们 可 以 看 到 , 主 表 (EMP) 通 过 连接 列 (DEPTNO) 传 值 给 子 表 (DEPT), :Bl 
就 表示 传 值 ， 主 表 (EMP) 的 连接 列 CDEPTNOO 基数 为 3， 所 以 被 驱动 表 (DEPT) 被 扫描 
T 3 次 。FILTER 一 般 在 整个 SQL 的 快要 执行 完毕 的 时 候 执 行 (Filter 的 Id 一 般 小 于 等 于 3)。 

请 注意 ， 执 行 计 划 中 还 有 一 种 FILTER, X% FILTER 只 起 过 滤 作 用 ， 这 类 FILTER ЕШ 
只 有 一 个 儿子 ， 谓 词 中 没有 exists， 也 没有 绑 定 变量 :B1， 例 子 如 下 。 


PLAN TABLE OUTPUT 





Id | Operation | Name | Rows | Bytes |Cost | 

0 | SELECT STATEMENT | | 1 || 81 | 1618| 
| 1 | SORT AGGREGATE | | 1 | 81 | 
SEU FILTER | | | | | 
5427 HASH JOIN OUTER | | | | | 

4 | NESTED LOOPS OUTER | | 642 | 38520 | 838| 
VEM INDEX FAST FULL SCAN | PK T SEND VEHICLE | 413 | $8260 | 121 
r € I TABLE ACCESS BY INDEX ROWID| T TASK HEAD | 2 || 80 | 2| 
ж 7/1 INDEX ВАМСЕ SCAN | IDX_TASK_VEHICLE_NO | 2.1 | 1 | 
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5.10 SQL 语句 的 本 质 


ШУЛ! TABLE ACCESS FULL | T TASK DETAIL | 162K|  3837K| 777) 









M 
T 
5 - filter(TRIM("SENDVEHICL1 "."SEND VEHICLE NO")-'01037041212280054') 

7 - access("TRANSTASKHO "."SEND VEHICLE NO" (+) =" SENDVEHICL1 "."SEND VEHICLE NO") 


我 们 在 做 SQL 优化 的 时 候 ， 一 般 只 需要 关注 FILTER 下 面 有 两 个 或 者 两 个 以 上 儿子 这 种 
FILTER。 关 于 如 何 避 免 执 行 计划 中 产生 FILTER 以 及 执行 计划 中 产生 了 FILTER 怎么 优化 ,请 
参阅 本 书 7.1 节 。 


我 相信 很 多 人 都 受到 过 in 与 exists 谁 快 谁 慢 的 困扰 。 如 果 执 行 计划 中 没有 产生 FILTER， 那 
么 我 们 可 以 参考 以 下 思路 : in 与 exists 是 半 连 接 ， 半 连接 也 属于 表 连 接 ， 那 么 既然 是 表 连 接 ， 我 
们 需要 关心 两 表 的 大 小 以 及 两 表 之 间 究 竟 走 什么 连接 方式 ， 还 要 控制 两 表 的 连接 方式 ， 才 能 随 
心 所 和 欲 优化 SQL， 而 不 是 去 记 什 么 时 候 in 跑 得 快 ， 什 么 时 候 exists 跑 得 快 。 如 果 执 行 计划 中 产 
生 了 FILTER， 大 家 还 需 阅读 7.1 节 才 能 彻底 知道 答案 。 


前 文 提 到 ， 标 量子 查询 可 以 改写 为 外 连接 (需要 注意 表 与 表 之 间 关 系 ， 去 重 )， 半 连接 可 
以 改写 为 内 连接 (需要 注意 表 与 表 之 间 关 系 ， 去 重 )， 反 连接 可 以 改写 为 外 连接 (不 需要 注意 
表 与 表 之 间 关 系 ， 也 不 需要 去 重 )。SQL 语句 中 几乎 所 有 的 子 查询 都 能 改写 为 表 连 接 的 方式 ， 
所 以 我 们 提出 这 个 观点 : SQL 语句 其 本 质 就 是 表 连 接 (内 连接 与 外 连接 )， 以 及 表 与 表 之 间 是 
几 比 几 关系 再 加 上 СКОРО BY. 
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жби 成 本 计算 






很 多 人 在 做 SQL 优化 的 时 候 都 会 去 看 Cost。 很 多 人 经 常 问 : 为 什么 Соя 很 小 , 但 是 SQL 
就 是 跑 很 久 不 出 结果 呢 ? 在 这 里 告诉 大 家 ,做 SQL 优化 的 时 候 根本 不 需要 去 看 Cost， 因 为 Cost 
是 根据 统计 信息 、 根 据 一 些 数学 公式 计算 出 来 的 。 正 是 因为 Cost 是 基于 统计 信息 、 基 于 数学 
公式 计算 出 来 的 ， 那 么 一 旦 统计 信息 有 误差 ， 数 学 公式 有 缺陷 ，Cost 就 算 错 了 。 而 一 旦 Cost 
计算 错误 ， 执 行 计划 也 就 错 了 。 当 SQL 需要 优化 的 时 候 ，Cost 往往 是 错误 的 ， 既 然 是 错误 的 
Cost， 我 们 干什么 还 要 去 看 Cost W? 
本 章 带 领 大 家 手动 计算 全 表 扫 描 以 及 索引 扫描 成 本 ， 同 时 由 此 引出 SQL 优化 核心 思想 。 


m.s 


本 实验 基于 Oraclell.2.0.1 Scott 账户 。 


| SOL» select * from v$version where rownum-1; 






Oracle Database 114 Enterprise Edition Release 11.2.0.1.0 - Production 
我 们 先 创 建 一 个 表 ， 名 为 t fullscan cost (注意 ， 只 需要 表 结 构 ， 不 要 数据 )。 
SQL» create table t fullscan cost as select * from dba objects where 1-0; 
Table created. 
我 们 设置 表 的 petfree 为 99%, 1Е2 — AER (8k) 只 能 存储 82byte 数据 。 
SQL> alter table t_fullscan_cost pctfree 99 pctused 1; 
Table altered. 
这 里 只 插入 一 行 数据 。 
SQL> insert into t fullscan cost select * from dba objects where rownum<2; 
1 row created. 
我 们 确保 表 中 一 个 块 只 存 一 行 数据 。 
| SOL» alter table t fullscan cost minimize records per block; 


Table altered. 


62 全 表 扫描 成 本 计算 


我 们 再 插入 999 行 数 据 。 


SQL» insert into t fullscan cost select * from dba objects where rownum«1000; 


999 rows created. 


接 下 来 提交 数据 。 


SQL> commit; 


Commit complete. 


我 们 收集 表 的 统计 信息 。 
SQL» BEGIN 
2 DBMS STATS.GATHER TABLE STATS (ownname => "SCOTT"; 
3 tabname -» 'T FULLSCAN COST', 
4 estimate percent => 100, 
5 method opt => 'for all columns size 1', 
6 degree => 1, 
7 cascade -> TRUE); 
8 END; 
9 y 


PL/SQL procedure successfully completed. 


我 们 查看 表 的 块 数 。 


SQL> select owner, blocks 
2 from dba tables 


3 where owner = 'SCOTT' 

4 and table name = 'T FULLSCAN COST'; 
OWNER BLOCKS 
SCOTT 1000 


这 里 设置 多 块 读 参数 为 16。 
SQL» alter session set db file multiblock read count-16; 


Session altered. 


我 们 查看 下 面 SQL 语句 执行 计划 。 


SQL> set autot trace 
SQL» select count(*) from t fullscan cost; 


Execution Plan 


Plan hash value: 387824861 


| Id | Operation | Name | Rows Cost ($CPU)| Time 

| 0 | SELECT STATEMENT | | 1 220 (0)1 00:00:03 | 
| 1 | SORT AGGREGATE | | 1 | | 
| 2 | TABLE ACCESS FULL| T FULLSCAN COST | 1000 220 (0)| 00:00:03 | 


执行 计划 中 T FULLSCAN COST 走 的 是 全 表 扫描 ，Cost 为 220。 那 么 这 220 是 怎么 算出 
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来 的 呢 ? 我 们 先 来 看 一 下 全 表 扫 描 成 本 计算 公式 。 | 
全 表 扫 描 成 本 的 计算 方式 如 下 。 | 


Cost = ( 
#SRds * sreadtim + 
#MRds * mreadtim + 
CPUCycles / cpuspeed 
) / sreadtime 


#SRds - number of single block reads 表示 单 块 读 次 数 
#MRds - number of multi block reads 表示 多 块 读 次 数 


#CPUCyles - number of CPU cycles CPU 时 钟 周 期 数 
sreadtim - single block read time 一 次 单 块 读 耗 时 ， 单 位 毫秒 
mreadtim - multi block read time 一 次 多 块 读 耗 时 ， 单 位 毫秒 
cpuspeed - CPU cycles per second 每 秒 CPU 时 钟 周期 数 


注意 : 如 果 没 有 收集 过 系统 统计 信息 (系统 的 CPU 速度 ， 磁 盘 VO 速度 等 )， 那 么 Oracle 
采用 非 工作 量 方式 来 计算 成 本 。 如 果 收 集 了 系统 统计 信息 ， 那 么 Oracle 采用 工作 量 统计 方式 
来 计算 成 本 。 一 般 我 们 是 不 会 收集 系统 的 统计 信息 的 。 所 以 默认 情况 下 都 是 采用 非 工作 量 
Cnoworkload) 方式 来 计算 成 本 。 

现在 我 们 来 看 一 下 系统 的 CPU 和 VO 情况 。 


SOL» select pname, pvall from sys.aux stats$ where sname-'SYSSTATS MAIN'; 








CPUSPEED 

CPUSPEEDNW 1683.65129 ---cpuspeed 
IOSEEKTIM 10 ---1/0 寻 道 寻 址 耗 时 
IOTFRSPEED 4096 ---1/0 传输 速度 
MAXTHR 

MBRC 

MREADTIM 

SLAVETHR 

SREADTIM 


因为 MBRC 为 NULL， 所 以 CBO 采用 了 非 工作 量 来 计算 成 本 。 

在 全 表 扫 描 成 本 计算 公式 中 ，#SRds=0， 因 为 是 全 表 扫 描 一 般 都 是 多 块 该 ，#MRds= 表 的 
块 数 /多 块 读 参 数 =1000/16，sreadtim=ioseektim-+db_block_size/iotfrspeed， 单 块 读 耗 时 =1/O Sibi 
寻 址 耗 时 + 块 大 小 /1/O 传输 速度 ， 所 以 单 块 读 耗 时 为 12 毫秒 。 


SQL» select (select pvall from sys.aux stats$ where pname = 'IOSEEKTIM') + 
2 (select value from v$parameter where name = 'db block size') / 
3 (select pvall from sys.aux stats$ where pname = 'IOTFRSPEED') "sreadtim" 
4 from dual; 
sreadtim 
12 


我 们 根据 单 块 读 耗 时 算法 ， 查 询 到 单 块 读 耗 时 需要 12 毫秒 。 


| mreadtim-ioseektim*db file multiblock count*db block size/iotftspeed 


多 块 读 耗 时 = VO 寻 道 寻 址 耗 时 + 多 块 读 参数 * 块 大 小 /IO 传输 速度 
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SQL» select (select pvall from sys.aux stats$ where pname = 'IOSEEKTIM') + 
2 (select value 
8 from v$parameter 4: 
4 where name = 'db file multiblock read count') * 
5 (select value from v$parameter where name - 'db block size') / 
6 (select pvall from sys.aux stats$ where pname - 'IOTFRSPEED') "mreadtim" 
2 from dual; 
mreadtim 
42 


我 们 根据 多 块 读 耗 时 算法 ， 查 询 到 多 块 读 耗 时 需要 42 毫秒 。 
CPUCycles $T PLAN TABL/V$SQL PLAN 里 面 的 CPU_COST。 
SQL> explain plan for select count(*) from t fullscan cost; 
Explained. 
SQL?» select cpu cost from plan table where rownum<=1; 

CPU COST 


7271440 


根据 以 上 信息 ， 我 们 现在 来 计算 全 表 扫描 成 本 。 


SOL» select (0 * 12 + 1000 / 16 * 42 / 12 + 7271440 / (1683.65129 * 1000) / 12) cost 


2 from dual; 
COST 
219.109904 


手动 计算 出 来 的 COST 值 为 219， 和 我 们 看 到 的 220 相差 1。 这 是 由 隐 含 参数 
 tablescan cost plus one 造成 的 (请 用 sys 运行 下 面 的 SQL). 


SQL> SELECT x.ksppinm NAME, y.ksppstvl VALUE, x.ksppdesc describ 


2 FROM x$ksppi x, x$ksppcv y 
3 WHERE x.inst id = USERENV ('Instance') 
4 AND y.inst id - USERENV('Instance') 
5 AND x.indx = y.indx 
6 AND x.ksppinm LIKE '$ table scan cost plus one$'; 
NAME VALUE DESCRIB 
table scan cost plus one TRUE bump estimated full table scan 


and index ffs cost by one 


该 参数 表示 在 TABLE FULL SCAN 或 者 在 INDEX FAST FULL SCAN 的 时 候 将 Cost 加 1。 
到 此 ， 我 们 终于 人 工 计 算出 全 表 扫 描 成 本 。 
全 表 扫 描 成 本 计算 公式 究竟 是 什么 含义 呢 ? 我 们 再 来 看 一 下 全 表 扫 描 成 本 计算 公式 。 


Cost = ( 
#SRds * sreadtim + 
#MRds * mreadtim + 
CPUCycles / cpuspeed 
) / sreadtime 
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因为 全 表 扫 描 没 有 单 块 读 ， 所 以 #SRds=0，CPU 耗费 的 成 本 基本 上 可 以 忽略 不 计 ， 所 以 我 
们 将 全 表 扫 描 公 式 变换 如 下 。 
Cost = ( 
#MRds * mreadtim 
) / sreadtime 
#MRds 表示 多 块 读 VO 次数, 那么 现在 我 们 得 到 一 个 结论 : 全 表 扫 描 成 本 公式 的 本 质 含义 
就 是 多 块 读 的 物理 vo 次 数 乘 以 多 块 读 耗 时 与 单 块 读 耗 时 的 比值 。 
全 表 扫 描 成 本 计算 公式 是 在 Oracle9i (2000 年 左右 ) 开始 引入 的 ， 当 时 的 UO 设备 性 能 
远 远 落后 于 现在 的 IO 设备 (磁盘 阵列 )， 随 着 SSD 的 出 现 ， 寻 道 寻 址 时 间 已 经 可 以 忽略 不 
计 ， 磁 盘 阵 列 的 性 能 已 经 有 较 大 提升 ， 因 此 认为 在 现代 的 IO 设备 (磁盘 阵列 ) 中 ， 单 块 读 
与 多 块 读 耗 时 几乎 可 以 认为 是 一 样 的 ， 全 表 扫 描 成 本 计算 公式 本 质 含义 就 是 多 块 读物 理 IO 
次 数 。 


本 实验 基于 Oracle11.2.0.1 Scott 账户 。 


| SOL» select * from v$version where гомпит=1; 












Oracle Database 119 Enterprise Edition Release 11.2.0.1.0 - Production 
我 们 先 创建 一 个 表 名 为 t_ indexscan cost. 
SQL» create table t indexscan cost as select * from dba objects; 
Table created. 
我 们 在 object id 列 上 建立 索引 如 下 。 
| SQL> create index idx cost on t indexscan cost(object id); 


Index created. 


收集 表 统 计 信 息 如 下 。 
SQL» BEGIN 
2 DBMS STATS.GATHER TABLE STATS (ownname -» 'SCOTT', 
3 tabname -» 'T INDEXSCAN COST', 
4 estimate percent -» 100, 
5 method opt => 'for all columns size 1", 
6 degree => 1, 
7 cascade => TRUE); 
8 END; 
9 


PL/SQL procedure successfully completed. 


我 们 查看 表 总 行 数 、object id 最 大 值 、object id 最 小 值 以 及 null 值 个 数 。 
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SQL» select b.num rows, 


2 a.num distinct, 

"5 a.num nulls, 

4 utl raw.cast to number(high value) high value, 
5 utl raw.cast to number(low value) low value, 

6 utl raw.cast to number(high value) - 

3 utl raw.cast to number(low value) "HIGH VALUE-LOW VALUE" 
8 from dba tab col statistics a, dba tables b 

9 where a.owner = b.owner 
10 and a.table name - b.table name 
11 and a.owner = 'SCOTT' 
1g and a.table name = ('T INDEXSCAN COST') 

13 and a.column_name = 'OBJECT_ID'; 


NUM ROWS NUM DISTINCT NUM NULLS HIGH VALUE LOW VALUE HIGH VALUE-LOW VALUE 


我 们 查看 下 面 SQL 语句 执行 计划 。 
SOL» select owner from t indexscan cost where object id«1000; 
942 rows selected. 
Execution Plan 


Plan hash value: 1756649757 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| 
| 0 | SELECT STATEMENT | | 951 | 10461 | 19 (0) | 
| 1 | TABLE ACCESS BY INDEX ROWID| T INDEXSCAN COST | 951 | 10461 | 19 (0) | 
ps 271 INDEX RANGE 5САМ | IDX COST | 951 | | 4 (0) | 


Predicate Information (identified by operation id): 


2 — access("OBJECT ID"«1000) 


执行 计划 中 ，T_INDEXSCAN_COST 表 走 的 是 索引 范围 扫描 。Cost 为 19。 那 么 这 Cost 


是 怎么 算出 来 的 呢 ? 我 们 先 来 看 一 下 索引 范围 扫描 的 成 本 计算 公式 。 


cost = 

blevel + 

celiling(leaf blocks *effective index selectivity) + 
celiling(clustering factor * effective table selectivity) 


索引 扫描 成 本 计算 公式 中 ，blevel、leaf blocks. clustering factor 都 可 以 通过 下 面 查询 得 到 。 


SQL» select leaf blocks, blevel, clustering factor 


2 from dba indexes 
3 where owner - 'SCOTT' 
4 and index name = 'IDX COST'; 
LEAF BLOCKS BLEVEL CLUSTERING FACTOR 
161 1 1113 


blevel 表示 索引 的 二 元 高 度 ，blevel 等 于 索引 高 度 -1，leaf blocks 表示 索引 的 叶子 块 个 数 ， 
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clustering factor 表示 索引 的 集群 因子 , effective index selectivity 表示 索引 有 效 选 择 性 , effective 
table selectivity 表示 表 的 有 效 选 择 性 。 

< 的 有 效 选择 性 为 : 

(limit-low value)/(high_value-low_value) 

(where 限制 条 件 -最 低 值 )( 最 高 值 -最 低 值 ) 

那么 这 里 有 效 选择 性 =(1000-2)/(76239-2)。 

执行 计划 中 ，CBO 估算 返回 的 Rows 为 951， 这 951 是 怎么 算出 来 的 呢 ? 

CBO 预 估 的 基数 = 有 效 选择 性 *( 总 行 数 -NULL Ж). 
| SQL» select ceil((1000-2)/(76239-2)*(72645-0)) from dual; 


CEIL((1000-2)/(76239-2)* (72645-0)) 


现在 大 家 应 该 理解 为 什么 我 们 曾 在 1.3 节 中 提出 执行 计划 中 的 Rows 都 是 假 的 这 个 观点 了 。 
如 果 where FRL, MWA СВО 在 估算 Rows 的 时 候 就 会 出 现 较 大 偏差 ， 而 且 通 常 将 Rows 
算 小 。 因 为 当 where 条 件 变 多 的 时 候 ，CBO 估算 返回 的 Rows= 某 列 选择 性 * 某 列 选择 性 * 某 列 
选择 性 *...* 表 总 行 数 ,选择 性 一 般 来 说 都 是 小 于 1 的 分 数 , 当 where 条 件 变 多 变 复 杂 之 后 , СВО 
估算 的 Rows= 小 于 1 的 分 数 * 小 于 1 的 分 数 * 小 于 1 的 分 数 *...* 表 的 总 行 数 ， 这 种 情况 下 Rows 
当然 会 越 算 越 小 〈 很 多 时 候 Rows 经 常 被 估算 为 1 )。 

根据 上 述 信息 ， 现 在 我 们 来 计算 索引 扫描 的 成 本 。 

SOL» select l+ceil(161*998/76237)+ceil(1113*998/76237) from dual; 


14CEIL (161*998/76237)4CEIL (1113*998/76237) 





手动 计算 出 来 的 成 本 为 19， 正 好 与 执行 计划 中 的 Cost 吻合 。 

在 1.4 节 中 我 们 曾经 提 到 ， 如 果 回 表 次 数 太 多 ， 就 不 应 该 索引 扫描 ， 而 应 该 走 全 表 扫 描 。 
我 们 也 可 以 从 索引 扫描 的 成 本 公式 中 验证 该 理论 。clustering factor * effective table selectivity 
表示 回 表 的 Cost， 在 示例 中 ， 回 表 的 Cost 为 15， 回 表 的 Cost 占据 整个 索引 扫描 Cost 的 79%. 
这 就 是 回 表 次 数 太 多 不 能 走 索 引 扫 描 的 原因 。 

索引 范围 扫描 成 本 计算 公式 的 本 质 含义 是 什么 呢 ? 我 们 再 来 看 一 下 索引 范围 扫描 的 成 本 
计算 公式 。 


cost = 

blevel + 

celiling(leaf_blocks *effective index selectivity) + 
celiling(clustering_factor * effective table selectivity) 


在 Oracle 数据 库 中 ，Btree 索引 是 树 形 结构 ， 索 引 范围 扫描 需要 从 根 扫描 到 分 支 ， 再 扫描 
到 叶子 。 叶 子 与 叶子 之 间 是 双向 指向 的 。blevel 等 于 索引 高 度 -1， 正 好 是 索引 根 块 到 分 支 块 的 
距离 。leaf blocks *effective index selectivity 表示 可 能 需要 扫描 多 少 叶子 块 。clustering factor * 
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effective table selectivity 表示 回 表 可 能 需要 耗费 多 少 ИО. 

索引 范围 扫描 是 单 块 读 ， 回 表 也 是 单 块 读 ， 因 此 ， 我 们 得 到 如 下 结论 : 索引 扫描 成 本 计算 
公式 其 本 质 就 是 单 块 读物 理 IO 次 数 。 

为 什么 全 表 扫 描 成 本 计算 公式 要 除 以 单 块 读 耗 时 呢 ? 上 文 提 到 ， 全 表 扫 描 COST= 多 块 读 
物理 VO 次 数 * 多 块 读 耗 时 / 单 块 读 耗 时 ， 索 引 范 围 扫 描 COST= 单 块 读物 理 VO 次 数 。 现 在 我 们 
对 全 表 扫描 COST 以 及 索引 范围 扫描 COST 都 乘 以 单 块 读 耗 时 : 

全 表 扫 描 COST* 单 块 读 耗 时 = 多 块 读物 理 UO 次 数 * 多 块 读 耗 时 = 全 表 扫 描 总 耗 时 

索引 范围 扫描 COST* 单 块 读 耗 时 = 单 块 读物 理 UO 次 数 * 单 块 读 耗 时 = 索引 扫描 总 耗 时 

到 此 ， 大 家 应 该 明白 优化 器 何 时 选择 全 表 扫 描 ， 何 时 选择 索引 扫描 ， 就 是 比较 走 全 表 扫 描 
的 总 耗 时 与 走 索 引 扫 描 的 总 耗 时 ， 哪 个 快 就 选 哪个 。 


[Т] зи кшш | 


现在 的 IT 系统 中 ，CPU 的 发 展 日 新 月 异 ， 内 存 技术 的 更 新 也 越 来 越 频 繁 ， 只 有 磁盘 技术 
发 展 最 为 迟缓 ， 磁 盘 〈1/O) 己 经 成 为 整个 IT 系统 的 瓶颈 。 在 6.2 节 中 ， 我 们 提 到 全 表 扫 描 的 
成 本 其 本 质 含义 就 是 多 块 读 的 物理 VO 次 数 ， 在 6.3 节 中 ， 我 们 提 到 索引 范围 扫描 的 成 本 其 本 
质 含义 就 是 单 块 读 的 物理 IO 次 数 。 我 们 在 判断 究竟 应 该 走 全 表 扫 描 还 是 索引 扫描 的 时 候 ， 往 
往 会 根据 两 种 不 同 的 扫描 方式 所 耗费 的 物理 IO 次 数 来 做 出 选择 , 哪 种 扫描 方式 耗费 的 物理 IO 
次 数 少 ， 就 选择 哪 种 扫描 方式 。 在 进行 SQL 优化 的 时 候 ， 我 们 也 是 根据 哪 种 执行 计划 所 耗费 
的 物理 IO 次 数 最 少 而 选择 哪 种 执行 计划 。 

基于 上 述 理论 , 我 们 给 出 整 本 书 的 核心 观点 : SQL 优化 的 核心 思想 就 是 想方设法 减少 SQL 
的 物理 IO 次 数 〈 不 管 是 单 块 读 次 数 还 是 多 块 读 次 数 )。 
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子 查 询 非典 套 (Subquery Unnesting): 当 where 子 查询 中 有 іп. not in, exists. not exists 
等 ，CBO 会 尝试 将 子 查询 展开 (unnest)， 从 而 消除 FILTER, 3x4 EFE fE ЕЕЕ. 
子 查询 非 帷 套 的 目的 就 是 消除 FILTER. 

现 有 如 下 SQL 及 其 执行 计划 (Oracle11.2.0.1)。 


SQL> select ename, deptno 


2 from emp 

3 where exists (select deptno 

4 from dept 

5 where dname = 'CHICAGO' 

6 and emp.deptno = dept.deptno 
Т union 

8 select deptno 

8 from dept 
10 where loc = 'CHICAGO' 
11 and dept.deptno - emp.deptno); 


6 rows selected. 
Execution Plan 


Plan hash value: 2705207488 




















| Id |Орегабіоп Name Rows Bytes | Cost($CPU)|Time 

| 0 |SELECT STATEMENT 5 45 15 (40) 100:00:01| 
| FILTER | 
| 2 TABLE ACCESS FULL EMP 14 126 3 (0) 100:00:01| 
ЕЕ SORT UNIQUE 2 24 A. (75) [00:00:01 | 
| 4 UNION-ALL | 
|ж,8 TABLE ACCESS BY INDEX ROWID| DEPT 1 13 1 (0) |00:00:011 
іне 16; INDEX UNIQUE 5САМ PK DEPT 1 0 (0) |00:00:011| 
| TABLE ACCESS BY INDEX ВОЙТО| DEPT 1 11. 1 (0) 100:00:011 
|% 8 INDEX UNIQUE SCAN PK DEPT 3 0 (0) 100:00:01| 


Predicate Information (identified by operation id): 


( (SELECT "DEPTNO" FROM "DEPT" "DEPT" WHERE 
."ЮЕРТМО"=# ВІ AND "DNAME"-'CHICAGO')UNION (SELECT "DEPTNO" FROM " 


1 - WE (is 
"DEPT 





DEPT" A 
"DEPT" WHERE "DEPT"."DEPTNO"-iB2 AND "LOC"-'CHICAGO'))) 
5 - filter("DNAME"-'CHICAGO!') 

6 - access ("РЕРТ"."РЕРТМО"= В) 

7 - filter("LOC"-'CHICAGO!') 
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і 8 - access ("РЕРТ". "ОЕРТМО"= ВШ) 


执行 计划 中 出 现 了 FILTER， 驱 动 表 因此 被 固定 为 EMP。 假 设 EMP 有 几 百 万 甚至 几 和 王 万 
行 数据 ， 那 么 该 SQL 效率 就 非常 差 。 


现在 将 上 述 SQL 改写 如 下 。 
SQL> select ename, deptno 
2 from emp 
3 where exists (select 1 
4 from (select deptno 
5 from dept 
6 where dname = 'CHICAGO' 
wt union 
8 select deptno from dept where loc = 'CHICAGO') a 
9 where a.deptno = emp.deptno); 


6 rows selected. 
Execution Plan 


Plan hash value: 4243948922 


Id Operation Name Rows Bytes Cost ($CPU)| Time 

0 SELECT STATEMENT 5 110 12 (25) | 00:00:01 

„М! HASH JOIN SEMI 5 110 12 (25)| 00200:01 
2 TABLE ACCESS FULL EMP 14 126 3 (0) 1 00:00:01 
3 VIEW 2 26 8 -(25)| 00:09:01 
4 SORT UNIQUE 1 24 8 (63) | 00:00:01 

| 5 UNION-ALL | 

< S TABLE ACCESS FULL| DEPT £ 13 3 (0) | 00:00:01 
7 TABLE ACCESS FULL| DEPT iE ud 3 (0) | 00:00:01 


























Predicate Information (identified by operation id): 


1 - access("A"."DEPTNO"-"EMP", "DEPTNO") 
6 - filter("DNAME"-'CHICAGO!') 
7 = filter("LOC"-'CHICAGO') 


对 SQL 进行 等 价 改写 之 后 ， 消 除了 FILTER。 为 什么 要 消除 FILTER ПЕ? 因为 FILTER 
的 驱动 表 是 固定 的 ， 一 旦 驱动 表 被 固定 ， 那 么 执行 计划 也 就 被 固定 了 。 对 于 ОВА 来 说 这 并 不 
是 好 事 ， 因 为 一 旦 固定 的 执行 计划 本 身 是 错误 的 ( 低 效 的 )， 就 会 引起 性 能 问题 ， 想 要 提升 性 
能 必须 改写 SQL 语句 ， 但 是 这 时 SQL 已 经 上 线 ， 无 法 更 改 ， 所 以 ， 一定 要 消除 FILTER, 

很 多 公司 都 有 开发 DBA， 开 发 DBA 很 大 一 部 分 的 工作 职责 就 是 : 必须 保证 SQL ERZ 
后 ， 每 个 SQL 语句 的 执行 计划 都 是 可 控 的 ， 这 样 才能 尽 可 能 避免 系统 中 SQL 越 跑 越 慢 。 

下 面 我 们 继续 对 上 述 SQL 进行 等 价 改写 。 


SQL> select ename, deptno 


2 from emp 

3 where deptno in (select deptno 

4 from dept 

5 where dname = 'CHICAGO' 
6 union 
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7 select deptno from dept where loc = 'CHICAGO'); 


6 rows selected. 


Execution Plan 


Plan hash value: 2842951954 























Id | Operation Name Rows Bytes Cost ($CPU)| Time 

| 0 | SELECT STATEMENT 9 198 i2 (28»] 00:00:01 

* Y | HASH JOIN 9 198 | i2 X25)1 0020001 
Ж VIEW VW NSO 1 2 26 8 (25)| 00:00:01 
3: 41 SORT UNIQUE 2 24 8 (63)| 00:00:01 
4 | UNION-ALL 

* 5 | TABLE ACCESS FULL| DEPT 1 13 3 (0)] 00:00:01 

* 61 TABLE ACCESS FULL| DEPT 1 IL] 3 (0)| 00:00:01 
Ж 41 TABLE ACCESS FULL EMP 14 126 3 (0) 00:00:01 


Predicate Information (identified by operation id): 


1 - access ("DEPTNO"-"DEPTNO") 
5 ~ filter("DNAME"-'CHICAGO') 
6 - filter("LOC"-'CHICAGO') 


将 SQL 改写 为 迄 之 后 ， 也 消除 了 FILTER, 
如 何 才能 产生 FILTER 呢 ? 我 们 只 需要 在 子 查 询 中 添加 /*+ no unnest */. 


SQL> select ename, deptno 





2 from emp 

3 where deptno in (select 

4 from 

5 where = 'CHICAGO' 

6 union 

7 select deptno from dept where loc = 'CHICAGO'); 


6 rows selected. 
Execution Plan 


Plan hash value: 2705207488 


























| Id |Орегабіоп Name Rows Bytes Cost (SCPU) | Time 

| 0 |SELECT STATEMENT 5 45 15 (40) |00:00:01 
ISA 

r 98 TABLE ACCESS FULL EMP 14 | 126 3 (0)100:00:01 
“3 SORT UNIQUE 2 24 4 (75) |00:00:01 
| 4 UNION-ALL | 

| 5 TABLE ACCESS BY INDEX ROWID| DEPT 1 13 出 (0) 100:00:01| 
(6 INDEX UNIQUE SCAN PK DEPT | 1 0 (0) |00:00:01 
INR TABLE ACCESS- BY INDEX ROWID| DEPT 521 11 1 (0) |00:00:01 
|* 8 INDEX UNIQUE SCAN | PK DEPT 1 0 (0) 100:00:01| 


Predicate Information (identified by operation id): 
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filter( ЕХІЗТ5 ( (SELECT /*- NO UNNEST */ "DEPTNO" FROM "DEPT" "DEPT" 
WHERE "DEPTNO"-$BI AND "DNAME"-'CHICAGO')UNION (SELECT "DEPTNO" FROM "D 


"DEPT" WHERE "DEPTNO"-:B2 AND "LOC"-'CHICAGO'))) 
filter ("DNAME"-'CHICAGO!') 
access ("DEPTNO"=:B1) 
filter ("LOC"-'CHICAGO') 
access ("БЕРТМО"- ВШ) 


大 家 可 能 会 问 ， 既 然 能 通过 HINT(NO_UNNEST) 让 执行 计划 产生 FILTER， 那 么 执行 计划 
中 如 果 产 生 了 FILTER, fX: HINT(UNNEST) 消 除 FILTER 呢 ? 执行 计划 中 的 FILTER 很 
少 能 够 通过 HINT 消除 ， 一 般 需 要 通过 SQL 等 价 改写 来 消除 。 

现在 我 们 对 产生 FILTER 的 SQL 添加 HINT(UNNEST) 来 尝试 消除 FILTER. 


SQL> s 
2 


3 
4 
5 
6 
T 
8 
9 
0 
1. 


6 rows 


Execut 


Predic 


1- 


DEPT" 


со -J ол 
I 





elect ename, deptno 
from emp 
where exists (select /%% unnest */ deptno 
from dept 
where dname = 'CHICAGO' 
and emp.deptno - dept.deptno 
union 
select deptno 
from dept 
where loc = 'CHICAGO' 
and dept.deptno = emp.deptno); 


selected. 
ion Plan 


| Name | Rows | Bytes | Cost($CPU)|Time 

| | Өм 45 | 15 (40) |00:00:01| 
lI | | | | | | 
l | EMP | 14 | 126 | 3 (0) |00:00:01| 
| SORT UNIQUE | | 2-| 24 | 4 (75) |00:00:01| 
| UNION-ALL | | | | | | 
| TABLE ACCESS BY INDEX ROWID| DEPT | 1. 1424) £ (0) 100:00:01| 
| INDEX UNIQUE 5САМ | PK DEPT | 1, | 0 (0) 100:00:01| 
І TABLE ACCESS BY INDEX ROWID| DEPT | 22! bi T. (0) 100:00:01| 
| INDEX UNIQUE SCAN | PK DEPT | 到 ч | 0 (0) 100:00:01| 


ate Information (identified by operation id): 


filter( EXISTS ( (SELECT /*- UNNEST */ "DEPTNO" FROM "DEPT" "DEPT" WHERE 
"DEPT"."DEPTNO"-$BI AND "DNAME"-'CHICAGO')UNION (SELECT "DEPTNO" FROM " 


"DEPT" WHERE "DEPT"."DEPTNO"-:B2 AND "LOC"-'CHICAGO'))) 
filter("DNAME"-'CHICAGO!') 
access ("DEPT"."DEPTNO"-$BÍ1) 
filter("LOC"-'CHICAGO') 
access ("БЕРТ"."ПЕРТМО"-:В1) 


123 


124 


执行 计划 中 还 是 有 FILTER。 再 次 强调 : 执行 计划 中 如 果 产 生 了 FILTER， 一 般 是 无 法 通 
it HINT 消除 的 ， 一 定 要 注意 执行 计划 中 的 FILTER。 

请 注意 ， 虽 然 我 们 一 直 强 调 要 消除 执行 计划 中 的 FILTER， 本 意 是 要 保证 执行 计划 是 可 控 
的 ， 并 不 意味 着 执行 计划 产生 了 FILTER 就 一 定性 能 差 ， 相 反 有 时 候 我 们 还 可 以 用 FILTER 来 
优化 SQL。 

哪些 SQL 写法 容易 产生 FILTER 呢 ? 当 子 查询 语句 含有 exists 或 者 not exists 时 ， 子 查询 
中 有 固化 子 查询 关键 词 Cunion/union all/start with connect by/rownum/cube/rollup)， 那 么 执行 计 
划 中 就 容易 产生 FILTER, Jl, exists 中 有 rownum 产生 FILTER. 


SQL» select ename, deptno 


2 from emp 

3 where ӨХЇБЕБ (select deptno 

4 from dept 

5 where loc = 'CHICAGO' 

6 and dept.deptno = emp.deptno 
7 and rownum <= 1); 





6 rows selected. 
Execution Plan 


Plan hash value: 3414630506 


| Id [Operation | Name | Rows | Bytes | Cost ($CPU)|Time 

| 0 |SELECT STATEMENT | | 5 | 45 | 6 (0) |00:00:011| 
|* 1 | ШШЕН | | | | | 
| 2 | TABLE ACCESS FULL | EMP | 14 | 126 | 3 (0) [00:00:01] 
|% 3| COUNT STOPKEY | | | | | | 
[* s=] TABLE ACCESS BY INDEX ROWID| DEPT | i 1 TL | 1 (0) |00:00:01| 
Тж”) INDEX UNIQUE 5САМ | PK DEPT | T^ | 0 (0)100:00:01| 


1 - filter( EXISTS (SELECT 0 FROM "DEPT" "DEPT" WHERE ROWNUM«-1 AND 
"DEPT". "DEPTNO"= AND "LOC"-'CHICAGO!')) 

3 - filter (ROWNUM«-1) 

4 - filter("LOC"-'CHICAGO') 

5 - access ("DEPT" . " DEPTNO"-$B1) 


exists 中 有 树 形 查 询 产生 FILTER. 


SQL> select * 
2 from dept 






3 where exists (select null 

4 

5 t.deptno - emp.deptno 
6 | H empno = 7698 

3 yy. prior empno = mgr); 








7.2 视图 合并 


Plan hash value: 4210865686 





| Id |Operation | Name | Rows | Bytes |Cost (%СРО) | 
|. 9 [SE STATEMENT | | ЕТІ 20 | 9 (0) | 
[w 1.7 @ R | | | | | 
| 2 | TABLE ACCESS FULL | -DEPT | 4 | 80 | 3 (0) | 
|* 3 | FILTER | | | | | 
каз CONNECT BY NO FILTERING WITH SW (UNIQUE) | | | | | 
( 1527) TABLE ACCESS FULL | EMP | 14 | 154 | 3 (0) | 


1 - filter( EXISTS (SELECT 0 FROM "EMP" "EMP" WHERE "EMP"."DEPTNO"-$BÍ START WITH 
"EMPNO"-7698 CONNECT BY "MGR'"-PRIOR "EMPNO")) 
3 - filter("EMP"."DEPTNO"-$BÍ) 
4 - access("MGR"-PRIOR "EMPNO") 
filter("EMPNO"-7698) 


为 什么 exists/not exists 容易 产生 FILTER, ifi in 很 少 会 产生 FILTER WE? 当 子 查询 中 有 固 
化 关键 字 Cunion/union all/start with connect by/rownum/cube/rollup)， 子 查询 会 被 固化 为 一 个 整 
Ж, 采用 exists/not exists 这 种 写法 ， 这 时 子 查询 中 有 主 表 连接 列 ， 只 能 是 主 表 通过 连接 列传 值 
给 子 表 ， 所 以 CBO 只 能 选择 FILTER。 而 我 们 如 果 将 SQL 改写 为 in/not in 这 种 写法 ， 子 查询 
虽然 被 固化 为 整体 ， 但 是 子 查 询 中 没有 主 表 连接 列 字 段 ， 这 个 时 候 CBO 就 不 会 选择 FILTER. 


视图 合并 (View Мегре): 当 SQL 语句 中 有 内 联 视 图 (in-line view, from 后 面 的 子 查询 )， 
或 者 SQL 语句 中 有 用 create view 创建 的 视图 , CBO 会 尝试 将 内 联 视 图 /视图 拆 开 , 进行 等 价 的 
改写 , 这 个 过 程 就 叫 作 视图 合并 。 如果 没 有 发 生 视 图 合并 , 在 执行 计划 中 , 我 们 可 以 看 到 VIEW 
关键 字 ， 而 且 视 图 / 子 查询 会 作为 一 个 整体 。 如 果 发 生 了 视图 合并 ， 那 么 视图 / 子 查询 就 会 被 拆 
开 ， 而 且 执 行 计划 中 视图 / 子 查询 部 分 就 没有 VIEW 关键 字 。 

现 有 如 下 SQL 及 其 执行 计划 (Oracle11.2.0.1)。 


SQL> select a.*, c.grade " 

from (select ename, sal, a.deptno, b.dname 
3 from emp a, dept b 

4 where a.deptno = b.deptno) a, 

5 salgrade c 

6 where a.sal between c.losal and c.hisal; 





N 


14 rows selected. 


Execution Plan 


Plan hash value: 3095952880 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| 
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| 0 | SELECT STATEMENT | | T 65 | 9 (2371 
| 1 | NESTED LOOPS | | | | | 
| Z1 NESTED LOOPS | | 1i] 65 | 9. 423) 
| 3 7 MERGE JOIN | | = S2. 8 (25) 
| 4 | SORT JOIN | | su 199%) 4 (25) 
| S TABLE ACCESS FULL | SALGRADE | 5 | 195 | 3 (0) | 
Eas | FILTER | | | | 

ааа АА | SORT JOIN | | 14 | 192 | 4 (25)| 
| 8 | TABLE ACCESS FULL | EMP l 14 | 182 | 3 (0) | 
pv. 4-1 INDEX UNIQUE SCAN | PK DEPT | 1.5 | 0 (0) | 
> 1 0 | TABLE ACCESS BY INDEX ROWIDI| DEPT | 1-4 13:41 1 (0) 





= filter ("SAL"<="C"."HISAL") 
= access ("SAL">="C". "LOSAL") 
filter ("SAL">="C" "LOSAL") 
9 - access ("A"."DEPTNO"-"B", "DEPTNO") 


SQL 语句 中 有 内 联 视图 ， 但 是 执行 计划 中 没有 VIEW 关键 字 ， 说 明 发 生 了 视图 合并 。 内 
联 视图 中 EMP 表 是 与 DEPT 表 关 联 的 , 但 是 执行 计划 中 , EMP 表 是 与 SALGRADE 先 关 联 的 ， 
EMP 表 与 SALGRADE 关联 之 后 得 到 一 个 结果 集 ， 再 与 DEPT 表 进 行 的 关联 ， 这 说 明 发 生 了 
视图 合并 之 后 ， 有 可 能 会 打 乱 视图 / 子 查询 中 表 的 原本 连接 顺序 。 

现在 我 们 添加 HINT:no_merge〈 子 查询 别名 /视图 别名 ) 禁止 视图 合并 ， 再 看 执行 计划 。 


SQL» select /*+ по merge(a) */ 
2 a.*, c.grade 
3 from (select ename, sal, a.deptno, b.dname 
Е from emp a, dept b 
5 where a.deptno = b.deptno) a, 
6 salgrade c 
7 where a.sal between c.losal and c.hisal; 


14 rows selected. 


Execution Plan 


Plan hash value: 4110645763 











| Id | Operation | Name | Rows Bytes | Cost ($CPU)| 
| 0 | SELECT STATEMENT | | 11 81 | 11 (28)| 
| 1 | MERGE JOIN | | 1 | 81 11 (28)| 
2 SORT JOIN | | 5 195 4 (25) 
3 TABLE ACCESS FULL | SALGRADE | 5 195 3 (0) 
4 FILTER | | 
5 SORT JOIN | | 14 588 7 (29) | 
6 VIEW | | 14 588 | Б SAMI 
7 MERGE JOIN | | 14 364 6. (17) 
8 TABLE ACCESS BY INDEX ROWID| DEPT | 4 52 2 (0) 
9 INDEX FULL SCAN | PK DEPT | 4 1 (0) 
|% 10 SORT JOIN | | 14 182 | 4 (25) 
11 TABLE ACCESS FULL | EMP | 14 | 182. J 3 (0) | 
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Predicate Information (identified by operation id): 


А = filter("A"."SAL"«-"C","HISAL") 

5 - access ("A"."SAL"W>="C"."LOSAL") 
filter("A","SAL"»-"C","TLOSAL") 

10 - access("A","DEPTNO"-"B". "DEPTNO") 
filter("A"."DEPTNO"-"B"."DEPTNO") 


执行 计划 中 有 VIEW 关键 字 ， 而 且 EMP 是 与 DEPT 进行 关联 的 ， 这 说 明 执 行 计划 中 没有 
发 生 视 图 合并 。 
我 们 也 可 以 直接 在 子 查询 里 面 添加 HINT:no merge 禁止 视图 合并 。 
SQL» select a.*, c.grade 
2 from (select /** по merge */ 
ename, sal, a.deptno, b.dname 


3 

E from emp a, dept b 

5 where a.deptno - b.deptno) a, 
6 
7 





salgrade c 
where a.sal between c.losal and c.hisal; 


14 rows selected. 


Execution Plan 


Plan hash value: 4110645763 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| 
| 0 | SELECT STATEMENT | | M 81 | 11 (28)] 
| 1 | MERGE JOIN | | 241 81 | 12 (28) 
| 2А | SORT JOIN | | Ex] 195») 4 (25)| 
І 9:1 TABLE ACCESS FULL | SALGRADE | S 195 | 3 (0) | 
12,242! FILTER | | | | | 
1 9. 1 SORT JOIN | | 14 | 588 | А. HZA 
| 6 | ТЕ | | 14 | 588 | 6 (E7)] 
| l MERGE JOIN | | 14 | 364 | 6 (17)| 
| 8 | TABLE ACCESS BY INDEX ROWID| DEPT | 4 | 52 | 2 (0) | 
| 9 | INDEX FULL SCAN | PK DEPT | 4 | | 1 (0) | 
PLO || SORT JOIN | | 14 | 182 | 4 (25) | 
|227 | TABLE ACCESS FULL | EMP | 14 | 182 | 3 (0) | 


Predicate Information (identified by operation id): 


4 - filter("A"."SAL"«-"C","HISAL") 

5 - access ("А". "SAL"»-"C","LOSAL") 
filter("A"."SAL"»-"C","LOSAL") 

10 - access ("A"."DEPTNO"-"B", DEPTNO") 
filter("A"."DEPTNO"-"B","DEPTNO") 


当 视 图 / 子 查询 中 有 多 个 表 关 联 ， 发 生 视 图 合并 之 后 一 般 会 将 视图 / 子 查询 内 部 表 关 联 顺序 
打 乱 。 


大 家 可 能 遇 到 过 类 似 案例 ， 例 如 下 面 SQL 所 示 。 
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| select ... from () a,() b where a.id-b.ig; 


单独 执行 子 查询 a， 速 度 非常 快 ， 单 独 执行 子 查询 b， 速 度 也 非常 快 ， 但 是 把 上 面 两 个 子 
查询 组 合 在 一 起 ， 速 度 反 而 很 慢 ， 这 就 是 典型 的 视图 合并 引起 的 性 能 问题 。 遇 到 类 似 问 题 ， 我 
们 可 以 添加 HINT:no merge 禁止 视图 合并 ， 也 可 以 让 子 查 询 a 与 子 查 询 b 进行 HASH 连接 ， 
当 子 查询 a 与 子 查询 b 进行 HASH 连接 之 后 ， 就 不 会 发 生 视图 合并 了 。 


| select /*+ use hash(a,b) */ ... from () a,() b where a.id-b.id; 


为 什么 让 子 查 询 a 与 子 查询 b 进行 HASH 连接 能 使 SQL 变 快 呢 ? 大 家 再 回忆 一 下 HASH 
连接 的 算法 ， 符 套 循 环 会 传 值 (驱动 表 传 值 给 被 驱动 表 ， 通 过 连接 列 )，HASH 连接 不 会 传 值 。 
因为 HASH 连接 不 传 值 ， 所 以 当 子 查询 a 与 子 查询 b 进行 HASH 连接 之 后 ， 会 自动 地 把 子 查 
询 a 与 子 查询 b 作为 一 个 整体 。 

与 子 查询 非 嵌 套 一 样 ， 当 视图 中 有 固化 子 查询 关键 字 的 时 候 ， 就 不 能 发 生 视图 合并 。 

固化 子 查 询 的 关键 字 包 括 union、union all、start with connect by, rownum, cube. rollup. 

现在 我 们 对 示例 SQL 添加 union all， 查 看 SQL 执行 计划 。 


SQL> select a.*, c.grade 
z from (select ename, sal, a.deptno, b.dname 
3 from emp a, dept b 
4 where a.deptno = b.deptno 
5 union all 
6 select 'SMITH', 1600, 10, 'ACCOUNTING' from dual) a, 
7 salgrade c 
8 where a.sal between c.losal and c.hisal; 


15 rows selected. 
Execution Plan 


Plan hash value: 1428389312 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| 
| 0 | SELECT STATEMENT | | а ^T 81 | 13 7(24)| 
| 1 | MERGE JOIN | | | 91 | 13 (24)| 
| 2 SORT JOIN | | S | 195 | 4 (25) 
| 3, 1 TABLE ACCESS FULL | SALGRADE | Si r55 | 3 (0) 
(ыс а | FILTER | | | | 

(* 38 | SORT JOIN | | 15! | 630 | 9 (2Зу| 
J 67 VIEW | | 15 | 630] 8 (13) | 
| 7.1 UNION-ALL | | | | 

| 8 | MERGE JOIN | | I4 | 364 | 6 (yl 
| 91 TABLE ACCESS BY INDEX ROWID| DEPT | 4 | S2 | 2 (0) | 
L0] INDEX FULL SCAN [ РЕ _ ЮЕРТ^ | 4 | | 1 (0) | 
IS cm. | SORT JOIN | | 14 | 182 | 4 (25)| 
5 Ж | TABLE ACCESS FULL | EMP | 14 | 182 | 3 (0) 
ІЗ. FAST DUAL | | L 1 | 2 (0) | 


4 = filter("A","SAL"«-"C","HISAL") 
5 - access ("A"."SAL"»-"C","LOSAL") 
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filter ("д" ."SAL"»-"C", "LOSAL") 


ll - access("A"."DEPTNO"-"B","DEPTNO") 
filter("A",."DEPTNO"-"B"."DEPTNO") 


从 执行 计划 中 我 们 可 以 看 到 ， 添 加 了 union all 之 后 ， 子 查询 被 固化 ， 没 有 发 生 视 图 合并 。 
现在 我 们 对 SQL 添加 rownum， 查 看 SQL 执行 计划 。 


SQL> select a.*, c.grade 


2 from (select ename, sal, a.deptno, b.dname 
3 from emp a, dept b 

4 where a.deptno - b.deptno 

5 and rownum >= 1) a, 
6 
T 


salgrade c 


where a.sal between c.losal and c.hisal; 


14 rows selected. 


Execution Plan 


Plan hash value: 819637296 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| 
| 0 | SELECT STATEMENT | | 18] 72% | 11 (28)! 
| 1 | MERGE JOIN | | 2.4 727 | 13-728) 
| 2 SORT JOIN | | Be i| 198 | 4 (25)| 
| 3 TABLE ACCESS FULL | SALGRADE | 5^] 195 | 3 (0)1 
(ж = &'| FILTER | | | | | 
Ше”! SORT JOIN l | 14 | 462 | 7 (09)| 
| 6 | VIEW | | 14 | 462 | (17)1 
| * | COUNT | | | | | 
>; 39] FILTER | | | І | 
| 9 | MERGE JOIN | | 14 | 364 | 6 {17i 
І 10) TABLE ACCESS BY INDEX ROWID| DEPT | 4 | 52 | 2 (0)1 
І 11% INDEX FULL SCAN | PK DEPT | 4 | | 1 (0) | 
|% 12-7 SORT JOIN | | 14 | 182 | À (25) | 
| 39 | TABLE ACCESS FULL | EMP | 14 | 182 | 3 (0)1 


4 - filter("A"."SAL"«-"C"., 


5 - access("A"."SAL"»-"C" 


8 - filter (ROWNUM»-1) 
12 - access ("A"."DEPTNO"-" 


"HISAL") 


."LOSAL") 
filter ("A","SAL"»-"C", 


B 


"LOSAL") 


"."DEPTNO") 


filter ("A"."DEPTNO"-"B"."DEPTNO") 


从 执行 计划 中 我 们 可 以 看 到 ， 添 加 了 rownum 之 后 ， 子 查询 同样 被 固化 ， 没 有 发 生 视 图 





谓词 推 入 (Pushing Predicate): 24 SQL 语句 中 包含 不 能 合并 的 视图 ， 同 时 视图 有 谓词 过 波 
(也 就 是 where 过 滤 条 件 )，CBO 会 将 谓词 过 滤 条 件 推 入 视图 中 ， 这 个 过 程 就 叫 作 谓词 推 入 。 
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谓词 推 入 的 主要 目的 就 是 让 Oracle 尽 可 能 早 地 过 滤 掉 无 用 的 数据 ， 从 而 提升 查询 性 能 。 


为 什么 谓词 推 入 必须 要 有 不 能 被 合并 的 视图 呢 ? 因为 一 旦 视图 被 合并 了 ， 执 行 计 划 中 根本 找 


不 到 视图 ， 这 个 时 候 谓 词 往 哪里 推 呢 ? 所 以 谓词 推 入 的 必要 前 提 是 SQL 中 要 有 不 能 合并 的 视图 。 


我 们 先 创 建 一 个 不 能 被 合并 的 视图 〈 视 图 中 有 union а). 
SOL> create or replace view v_pushpredicate as 

2 select * from test 

3 union all 

4 select % from test where rownum>=l; 
View created. 

然后 我 们 运行 下 面 的 SQL， 同 时 查看 执行 计划 。 
SQL» select * from v pushpredicate where object id«10; 


16 rows selected. 


Execution Plan 








| 5T Operation Name | Rows | Bytes | Cost ($CPU)| 
| 0 1 SELECT STATEMENT | | 72470 | 14M| 238 (1) 1 
І | тй | V_PUSHPREDICATE | 72470 | 14M| 238 (1) | 
2 UNION-ALL | | 

ІШ 5) TABLE ACCESS BY INDEX ROWID| TEST | 8 | 7486) | 3 (0) | 
Eg | INDEX RANGE SCAN IDX ID | 8 | | 2 (0) | 
11 #5 4 COUNT | | | 

[Ж 6 FILTER | | | 

ім 7 TABLE ACCESS FULL TEST | 72462 | 6864К| 235 (1)1 


1 - filter("OBJECT ID"«10) 
4 - access("OBJECT ID"«10) 
6 - filter (ROWNUM»-1) 


SQL 语句 中 ，where 过 滤 条 件 是 针对 视图 过 滤 的 ， 但 是 从 执行 计划 中 《〈Id=4) 我 们 可 以 看 


到 ，where 过 滤 条 件 跑 到 视图 中 的 表 中 进行 过 滤 了 ， 这 就 是 谓词 推 入。 因为 视图 中 第 二 个 表 有 


rownum, rownum 会 阻止 谓词 推 入 ， 所 以 第 二 个 表 走 的 是 全 表 扫 描 ， 需 要 到 视图 上 进行 过 滤 
(Id=1), 


我 们 在 看 执行 计划 的 时 候 , 如果 VIEW 前 面 有 “*” 号 , 这 就 说 明 有 谓词 没有 推 入 到 视图 中 。 
一 般 情况 下 , 常量 的 谓词 推 入 对 性 能 的 提升 都 是 有 益 的 。 那么 什么 是 常量 的 谓词 推 入 呢 ? 


常量 的 谓词 推 入 就 是 谓词 是 正常 的 过 滤 条 件 ， 而 非 连 接 列 。 


在 2011 年 我 们 曾 帮 网 友 做 过 一 次 常量 谓词 推 入 优化 ， 因 为 实在 是 太 简单 ， 所 以 没有 将 其 


纳入 书 中 .有 兴趣 的 读者 可 以 参考 博客 : http://blog.csdn.net/robinson1988/article/details/6613851。 


还 有 一 种 谓词 推 入 , 是 把 连接 列 当 作 谓词 推 入 到 视图 中 , 这 种 谓词 推 入 我 们 一 般 叫 作 连 接 
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列 谓词 推 入 ， 此 类 谓词 推 入 最 容易 产生 性 能 问题 。 
现在 我 们 将 上 面 视图 中 的 rownum 去 掉 (为 了 使 连接 列 能 推 入 视图 )。 
SQL» create or replace view v pushpredicate as 
2 select * from test 
3 union all 
4 select % from test; 


View created. 


我 们 添加 HINT:push pred 提示 将 连接 列 推 入 到 视图 中 。 


SQL» select /**/push ргеа(в) = 





2 from test a, v pushpredicate b 
3 where a.object id - b.object id 
4 and a.owner = 'SCOTT'; 


14 rows selected. 








Execution Plan 
Plan hash value: 2131469559 | 


























та Operation Name Rows Bytes Cost ($CPU) 
0 SELECT STATEMENT 4997 1444K| 10073 (1) 
1 NESTED LOOPS 4997 1444K| 10073 (1) 
2 TABLE ACCESS BY INDEX ROWID TEST 2499 236K TS (0) 
* 3 INDEX RANGE SCAN IDX OWNER 2499 6 (0) 
4 VIEW V PUSHPREDICATE 1 199 4 (0) 

5 UNION ALL PUSHED PREDICATE | 

6 TABLE ACCESS BY INDEX ROWID| TEST ИЕ) 97 2 (0) | 
591 INDEX RANGE SCAN IDX ID 4: 4 (0) 
8 TABLE ACCESS BY INDEX ROWID| TEST 1 97 2 (0) 
* 9 INDEX RANGE SCAN IDX ID 1 Дз 260) 


Predicate Information (identified by operation id): 


3 - access ("A"."OWNER"-'SCOTT') 
"n m access ("OBJECT ID"-"A","OBJECT ID") 
9:- access ("OBJECT ID"-"A"."OBJECT ID") 


将 连接 列 推 入 到 视图 中 这 种 谓词 推 入 , 一 般 在 执行 计划 中 都 能 看 到 PUSHED PREDICATE 
或 者 VIEW PUSHED PREDICATE， 而 且 视 图 一 般 作为 髓 套 循环 的 被 驱动 表 ， 同 时 视图 中 谓词 
被 推 入 列 有 索引 。 这 种 谓词 推 入 对 性 能 有 好 有 坏 。 为 什么 连接 列 谓词 推 入 , 被 推 入 的 视图 一 般 
都 作为 嵌 套 循环 的 被 驱动 表 呢 ? 这 是 因为 连接 列 谓词 推 入 需要 传 值 〈 传 值 到 视图 里 面 )， 而 有 
传 值 操作 的 表 连 接 方法 只 有 舱 套 循环 或 者 FILTER, FILTER 是 专门 针对 半 连 接 或 者 反 连 接 的 
(where 后 面 的 子 查 询 )， 谓 词 推 入 是 专门 针对 from 后 面 的 子 查询 ， 所 以 连接 列 谓词 推 入 ， 被 
推 入 的 视图 一 般 都 作为 笑 套 循环 的 被 驱动 表 。 

在 本 书 示 例 中 ， 连 接 列 谓词 推 入 的 执行 计划 是 最 优 执行 计划 。 驱 动 表 test 过 滤 之 后 
(owner='SCOTT') 只 返回 7 行 数据 ， 然 后 通过 连接 列传 值 7 次 ， 传 入 视图 中 ， 视 图 里 面 的 表 
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кта езжен _ _—_— e. 
走 的 是 索引 扫描 ， 因 为 驱动 表 7 次 传 值 ， 所 以 被 驱动 表 〈 视 图 ) 一 共 被 扫描 了 7 次 ， 但 是 每 次 
扫描 都 是 索引 扫描 。 

现在 我 们 去 掉 HINT:push pred. 

SOL» select * 

2 from test a, v pushpredicate b 

3 where a.object id - b.object id 

4 and a.owner = 'SCOTT'; 


14 rows selected. 


Execution Plan 




















Id Operation Name Rows Bytes Cost ($CPU) 
0 SELECT STATEMENT 4997 1483К 544 (1) 
s HASH JOIN 4997 1483K 544 (1) 
2 TABLE ACCESS BY INDEX ROWID| TEST 2499 236K 73 (0) 
теа INDEX ВАМСЕ SCAN IDX OWNER 2499 6 (0) 
4 VIEW V PUSHPREDICATE 144K 28M 470 (1) 
5 UNION-ALL 
6 TABLE ACCESS FULL TEST 72462 6864K 235 (1) 
7. TABLE ACCESS FULL TEST 72462 6864K 24% (1) 
Predicate Information (identified by operation id): 





Tl = access("A"."OBJECT ID"-"B","OBJECT ID") 
3 - access ("A"."OWNER"-'SCOTT') 


在 本 书 示 例 中 , 我们 如 果 不 将 连接 列 推 入 到 视图 中 ,视图 里 面 的 表 就 只 能 全 表 扫 描 ， 这 时 
性 能 远 不 如 索引 扫描 ， 所 以 本 书 示 例 最 佳 执行 计划 就 是 连接 列 谓词 推 入 的 执行 计划 。 

笔者 经 常 遇 到 连接 列 谓 词 推 入 引起 SQL 性 能 问题 。 大 家 在 工作 中 ， 如 果 遇 到 执行 计划 
中 VIEW PUSHED PREDICATE 一 定 要 注意 ， 如 果 SQL 执行 很 快 ， 不 用 理会 ;如果 SQL 执 
行 很 慢 ， 可 以 先 关 闭 连接 列 谓词 推 入 Calter session set " push join predicate" = false) 功能 ， 
再 逐步 分 析 为 什么 连接 列 谓词 推 入 之 后 ，SQL 性 能 很 差 。 连 接 列 谓词 推 入 性 能 变 差 一 般 是 
СВО 将 驱动 表 Rows 计算 错误 ( 算 少 )， 导 致 视图 作为 嵌 套 循环 被 驱动 表 ， 然 后 一 直 反 复 被 
扫描 ; 也 有 可 能 是 视图 太 过 复杂 ， 视 图 本 身 存在 性 能 问题 ， 这 时 需要 单独 优化 视图 。 例 如 视 
图 单独 执行 耗 时 1 秒 ， 在 进行 谓词 推 入 之 后 ， 视 图 会 被 扫描 多 次 ， 假 设 扫描 1 000 次 ， 每 次 
执行 时 间 从 1 秒 提升 到 了 0.5 秒 ， 但 是 视图 被 执行 了 1 000 次 ， 总 的 耗 时 反而 多 了 ， 这 时 谓 
词 推 入 反而 降低 性 能 。 

一 定 要 注意 ， 当 视图 中 有 rownum 会 导致 无 法 谓词 推 入 ， 所 以 一 般 情况 下 ,我 们 不 建议 在 
视图 中 使 用 rownum。 为 什么 rownum 会 导致 无 法 谓词 推 入 呢 ? 这 是 因为 当 谓 词 推 入 之 后 ， 
rownum 的 值 已 经 发 生 改 变 ， 已 经 改变 了 SQL 结果 集 ， 任 何 查询 变换 必须 是 在 不 改变 SQL 结 
采集 的 前 提 下 才能 进行 。 
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在 1.3 节 中 提 到 , 执行 计划 中 的 Rows 是 假 的 , 是 СВО 根据 统计 信息 和 数学 公式 估算 出 来 
的 ， 所 以 在 看 执行 计划 的 时 候 ， 一 定 要 注意 幅 套 循环 驱动 表 的 Rows 是 否 估算 准确 ， 同 时 也 要 
注意 执行 计划 的 入 口 Rows 是 否 算 错 。 因 为 一 旦 嵌 套 循环 驱动 表 的 Rows 估算 错误 ， 执 行 计划 
就 错 了 。 如 果 执 行 计划 的 入 口 Rows 估算 错误 ， 那 执行 计划 也 就 不 用 看 了 ， 后 面 全 错 。 

现 有 如 下 执行 计划 。 


SQL» select * from table(dbms xplan.display); 





PLAN TABLE OUTPUT 


Plan hash value: 3215660883 


0 |SELECT STATEMENT | | 78| 4212 | 15507 (1)| 
1 | HASH GROUP BY | | 78| 4212 | 15507 (1)| 
2 | NESTED LOOPS | | | | | 
| | 159K| 15506 (1)| 
101K| 650 (14)| 

| 2 (0) 









^") О INDEX RANGE SCAN | PROD | DIM : PK 
ж G TABLE ACCESS BY INDEX ROWID|PROD _ DIM ` 








AU 'UOM' Eu JRR Q' =1 
5 = access "PROD". "PROD ` SL Dm "00м". "PROD SKID") 
6 - filter("PROD"."BUOM | CURR SKID” IS NOT NULL AND "PROD"."PROD END DATE"-TO DATE(' 
9999-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "PROD"."CURR IND"-' 


Y' AND 
"PROD"."BUOM CURR SKID"-"UOM"."UOM SKID") 


22 rows selected. 


执行 计划 中 14-4 дЕ УА 95) 0, АЫ ИТУ А 1, СВО 估算 它 只 返回 
2967 行 数据 。Id=4 前 面 有 “*” 号 ， 表 示 有 谓词 过 滤 4 - filter ("ООМ". "КЕТУ CURR 
туты) 

根据 执行 计划 中 Id=4 的 谓词 信息 ， 手 动 计算 Id=4 应 该 返回 真正 的 Rows # F , 


| SQL» select count(*) from OPT REF UOM TEMP SDIM where "RELTV CURR QTY"-1; 








946432 


手动 计算 出 的 Rows 返回 了 946 432 行 数据 ， 与 执行 计划 中 的 2967 行 相差 巨大 ， 所 以 本 
示例 中 ， 执 行 计划 是 错误 的 。 


当 SQL 语句 中 同时 有 or 和 子 查询 , 这 种 情况 下 子 查询 无 法 展开 (unnest), 只 能 走 FILTER. 
遇 到 这 种 情况 我 们 可 以 将 SQL 改写 为 union， 从 而 消除 FILTER. 
带 有 or 子 查询 的 写法 与 执行 计划 如 下 。 


SOL» select * 





2 from ti 
3 where owner гац 
4 or d 






72571 rows selected. 
Execution Plan 


Plan hash value: 895956251 








| Id | Operation | Name | Rows | Bytes | Cost (%СРО) | Time 

| 0 | SELECT STATEMENT | | 3378 | 682K| 235 (1)| 00:00:03 
ЕЕ eg Ë | | | | | | 
| 2 1 TABLE ACCESS FULL| Т1 | 56766 | 11М| 235 (1) | 00:00:03 
jos 3 TABLE ACCESS FULL| T2 | 734.11. 9542 | 2 (0)| 00:00:01 







'S (SELECT 0 FROM "T2" "T2" WHERE 
"OBJECT ID" 
3 - filter("OBJECT ID' 


改写 为 union 的 写法 如 下 。 


SQL> select * from tl where owner='SCOTT' 
2 union 
3 select * from tl where object id in(select object id from t2); 


72571 rows selected. 
Execution Plan 


Plan hash value: 696035008 


| Id | Operation | Name | Rows | Bytes |TempSpc| Cost ($CPU)| 
| 0 | SELECT STATEMENT | | 56778 | 11MI | 4088 (95) | 
| 1 | SORT UNIQUE | | 5677® | 11M| 12M| 4088 (95) | 
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| 2-1 UNION-ALL | | | | | | 
p* 3] TABLE ACCESS FULL | Т1 | 12 | 2484 | | 234 (2.3 
|* 3] HASH JOIN | | 56766 | 11M| 1800К|. .1146 (1)1 
| БІ | TABLE ACCESS FULL| Т2 | 73407 | 931K| | 234 (1) | 
| 6: | TABLE ACCESS FULL| Т1 | 56766 | 11M| | 235 (1) 


3 ~ filter("OWNER"-'SCOTT"') 
4 - access("OBJECT ID"-"OBJECT ID") 


改写 为 union 之 后 ， 消 除了 FILTER。 如 果 无 法 改写 SQL， 那 么 SQL 就 只 能 走 FILTER, 
这 时 我 们 需要 在 子 查询 表 的 连接 列 (t2.object_ id) 建立 索引 。 


分 页 语句 最 能 考察 一 个 人 究竟 会 不 会 SQL 优化 ， 因 为 分 页 语句 优化 几乎 宫 括 了 SQL 优化 
必须 具备 的 知识 。 


8.31 单 表 分 页 优化 思路 
我 们 先 创建 一 个 测试 表 T_PAGE。 


SQL> create table t page as select * from dba objects; 





Table created. 


现 有 如 下 SQL〔 没 有 过 滤 条 件 ， 只 有 排序 )， 要 将 查询 结果 分 页 显示 ， 每 页 显示 10 Ж. 


| Select * from t page order by object id; 


大 家 可 能 会 采用 以 下 这 种 分 页 框架 (错误 的 分 页 框架 )。 


select * 
from 
where 

and 13 


采用 这 种 分 页 框架 会 产生 严重 的 性 能 问题 。 现 在 将 SQL 语句 代入 错误 的 分 页 框架 中 。 


SOL» select * 
2 from (select t.*, rownum rn 
3 from (select * from t page order by object id) t) 
4 where rn >= 1 
5 and rn <= 10; 





t.*, rownum rn from 





t) 


10 rows selected. 


Execution Plan 


Plan hash value: 3603170480 


| Id | Operation | Name | Rows | Bytes |TempSpc| Cost ($CPU)| 
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| 0 | SELECT STATEMENT | | 61800 | 12M| | 3020 (1)1 
|ж 1| VIEW | | 61800 | 12M| 3020 611 
| 2. | COUNT | | | | | | 
| 3 | VIEW | | 61800 | 12M| | 3020 (1)| 
| 4. || SORT ORDER BY | | 61800 | 12M| 14M| 3020 (1)1 
| $^ TABLE ACCESS FULL| T PAGE | 61800 | 12M| | 236 (131 


1 - filter("RN"<=10 AND "RN">=1) 


从 执行 计划 中 我 们 可 以 看 到 该 SQL 走 了 全 表 扫 描 ， 假 如 T PAGE 有 上 亿 条 数据 ， 先 要 将 
该 表 (上 亿 条 的 表 ) 进行 排序 (SORT ORDER BY)， 再 取出 其 中 10 行 数 据 ， 这 时 该 SQL 会 
产生 严重 的 性 能 问题 。 所 以 该 SQL 不 能 走 全 表 扫 描 ， 必 须 走 索引 扫描 。 
该 SQL 没有 过 滤 条 件 ， 只 有 排序 ,我 们 可 以 利用 索引 已 经 排序 这 个 特性 来 优化 分 页 语句 ， 
也 就 是 说 要 将 分 页 语句 中 的 SORT ORDER BY 消除 。 一 般 分 页 语句 中 都 有 排序 。 
现在 我 们 对 排序 列 object id 建立 索引 ， 在 索引 中 添加 一 个 常量 0， 注意 0 不 能 放 前 面 。 
SQL» create index idx page оп t page (object іа,0); 


Index created. 


为 什么 要 在 索引 中 添加 一 个 常量 0 WE? 这 是 因为 object id 列 允 许 为 null, 如 果 不 添加 常量 
(不 一 定 是 0， 可 以 是 1、2、3， 也 可 以 是 英文 字母 )， 索 引 中 就 不 能 存储 null 值 ， 然 而 SQL 并 
没有 写成 以 下 写法 。 


| select * from t page Whezero 





ШІ order by object id; 


因为 SQL 中 并 没有 剔除 null ii 所 以 我 们 必须 要 添加 一 个 常量 ， 让 索引 存储 null 值 ， 这 
样 才能 使 SQL 走 索引 。 现 在 我 们 来 看 一 下 强制 走 索 引 的 A-Rows 执行 计划 (因为 涉及 到 排版 
和 美观 ， 执 行 计 划 中 删 掉 了 A-Time 等 数据 )。 
SQL» select * from table(dbms xplan.display cursor(null,null,'ALLSTATS LAST')); 


PLAN TABLE OUTPUT 


select * from (select t.*, rownum rn from (select 
/** index(t page idx page) */ * 
from t_page order by object id) t) where rn >= 1 


and rn «- 10 


Plan hash value: 3119682446 


| Id |Operation | Name | Starts | E-Rows | A-Rows | Buffers | 
| 0 |SELECT STATEMENT | | Жу | | 10 | 1287 | 
|* 1 | VIEW | | 1 |F 61800 | 10 | 1287 | 
| 2 1 COUNT | | T | 72608 | 1287 | 
ІІ 271 VIEW | | 1 | “61800 | 72608 | 1287 | 
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ХОЙШ | T PAGE | 1 | 61800 | 172608 | 
| ТОХ_РАСЕ | 1 | 61800 | Б | 








1 - filter(("RN"<=10 AND "RN">=1)) 


因为 SQL 语句 中 没有 where 过 滤 和 条件， 强制 走 索 引 只 能 走 INDEX FULL SCAN, TRE 
索引 范围 扫描 (INDEX RANGE SCAN). 我 们 注意 看 执行 计划 中 A-Rows 这 列 ，INDEXFULL 
SCAN 扫描 了 索引 中 所 有 叶子 块 ， 因 为 INDEX FULL SCAN 返回 了 72 608 行 数据 ( 表 的 总 行 
数 )， 一 共 耗 费 了 1 287 个 逻辑 读 (Buffers=1287)。 理 想 的 执行 计划 是 : INDEX FULL SCAN 
只 扫描 1 个 (最 多 几 个 ) 索引 叶子 块 ， 扫 描 10 行 数 据 (A-Rows=10) 就 停止 了 。 为 什么 没有 
走 最 理想 的 执行 计划 呢 ? 这 是 因为 分 页 框架 错 了 ! 

下 面 才 是 正确 的 分 页 框架 。 


select * 
from (select * 
from (select a.*, rownum 1 
from (W 要 分 了 $ SOL) a) 
where rownum <= 10) 
where rn >= 1; 


现在 将 SQL 代入 正确 的 分 页 框架 中 ， 强 制 走 索 引 ， 查 看 A-Rows 的 执行 计划 (因为 涉及 
到 排版 和 美观 ， 执 行 计划 中 删 掉 了 A-Time 等 数据 )。 


SOL» select * from table (dbms_xplan.display_cursor(null,null,'ALLSTATS LAST')); 






PLAN TABLE OUTPUT 


select * from (select * from (select a.*, rownum rn 
from (select /*+ index(t page idx page) */ 

from t page 
order by object id) a) where rownum <= 10) where rn >= 1 


* 


Plan hash value: 1201925926 






| Id |Орегабіоп Name Starts E-Rows A-Rows |Buffers 
| 0 |SELECT STATEMENT 1 10 5 
ГДЕ VIEW 1 10 10 5 
|* 2 т &EOUNT BTOPKEY 1 10 5 
| 22%) VIEW 1 61800 | 19 5 
| 34 COUNT 1 10 5 
[18 УТЕЙ 1 61800 10 5 
l „Ё Т_РАСЕ 1 61800 10 5 
jog IDX PAGE 1 61800 10 3 
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| 1 - filter ("ВМ">=1) 

2 - filter (ROWNUM<=10) 

从 执行 计划 中 我 们 可 以 看 到 ，SQL 3E Y INDEX FULL SCAN， 只 扫描 了 10 条 数据 (14=7 
A-Rows=10) 就 停止 了 (Id=2 COUNT STOPKEY)， 一 共 只 耗费 了 5 个 逻辑 读 (Buffers=5)。 
该 执行 计划 利用 索引 已 经 排序 特性 (执行 计划 中 没有 SORT ORDER BY), 扫描 索引 获取 了 10 
条 数据 ; 然后 再 利用 了 COUNT STOPKEY 特性 ， 获 取 到 分 页 语句 需要 的 数据 ，SQL 立即 停止 
运行 ， 这 才 是 最 佳 执行 计划 。 

为 什么 错误 的 分 页 框架 会 导致 性 能 很 差 呢 ? 因为 错误 的 分 页 框架 这 种 写法 没有 
COUNT STOPKEY(where rownum<=...) 功 能 ，COUNT STOPKEY 就 是 当 扫 描 到 指定 行 数 的 数 
据 之 后 ，SQL 就 停止 运行 。 

现在 我 们 得 到 分 页 语句 的 优化 思路 : 如 果 分 页 语句 中 有 排序 (order by)， 要 利用 索引 已 经 
排序 特性 ， 将 order by 的 列 包含 在 索引 中 ， 同 时 也 要 利用 rownum 的 COUNT STOPKEY 特性 
来 优化 分 页 SQL。 如 果 分 页 中 没有 排序 ， 可 以 直接 利用 rownum 的 COUNT STOPKEY 特性 来 
优化 分 页 SQL. 

现 有 如 下 SQL (注意 ， 过 滤 条 件 是 等 值 过 滤 ， 当 然 也 有 order by)， 现 在 要 将 查询 结果 分 
页 显 ж» 每 页 显示 10 条 。 
| 


select * from t page where Owner = "5СОТТ" order Бу object id; 
select * from t page where Owner = 'SYS* order by object id; 


第 一 条 SQL 语句 的 过 滤 条 件 是 where owner='SCoTT'， 该 过 滤 条 件 能 过 滤 掉 表 中 绝 大 
部 分 数据 。 第 二 条 SQL 语句 的 过 滤 条 件 是 where owner='sYS'， 该 过 滤 条 件 能 过 滤 表 中 一 
我 们 将 上 述 SQL 代入 正确 的 分 页 框架 中 强制 走 索 引 Cobject id 列 的 索引 ， 因 为 到 目前 为 
iE t page 只 有 该 列 建立 了 索引 )， 查 看 A-Rows 的 执行 计划 因为 涉及 到 排版 和 美观 ， 执 行 计 
划 中 删 掉 了 A-Time 等 数据 )。 
SQL» select * from table(dbms xplan.display cursor(null,null,'ALLSTATS LAST')); 


PLAN TABLE OUTPUT 


select * from (select * from (select a.*, rownum rn 
from (select 7%% index(t page idx page) */ 
from t page 
where owner - 'SCOTT' order by object id) a) 
where rownum «- 10) where rn »- 1 


* 


Plan hash value: 1201925926 


| Id | Operation | Name | Starts | E-Rows | A-Rows |Buffers| 
| 0 | SELECT STATEMENT | | 2. | to] 1273| 
[* 1 | VIEW | | d šj 20-1 10 | 1273| 
ж 2 1 COUNT 5ТОРКЕҮ | | T. | 10 | 1273| 
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| 3| VIEW | | 11 57 | Low 4273 
J^ У, COUNT | | 1| | NOU 72213 
M A, | 133 B» 20: 19:912731 
|% 671 | M 57 | ШІ |! 

ақ | 11 61800 | m72427 | 183 








1 - filter ("RN">=]1) 
2 - filter (ROWNUM<=10) 
6 – filter("OWNER"-'SCOTT') 


SQL» select * from table(dbms xplan.display cursor(null,null,'ALLSTATS LAST')); 


PLAN TABLE OUTPUT 


select * from (select * from (select a.*, rownum rn 
from (select dex(t page idx page) */ 





раче rus t] i 
from t page 
where owner = 'SYS' order by object id) a) 

where rownum <= 10) where rn >= 1 


* 


Plan hash value: 1201925926 


| Id [Operation | Name | Starts | E-Rows | A-Rows |Buffers| 
| 0 |SELECT STATEMENT | | T || | TO 5 | 
1+ 1 | VIEW | | k J 10- | EOI 5| 
|% 2 | COUNT STOPKEY | | 1! | О 54 
9 Ж VIEW | | 11| 28199 | 10 | 5 | 
MEE NT COUNT | | % 1 | 109 | 5| 
[276.11 VIEW | | J | 28199 | 10 | 5| 
1% 161 | 32 | | 

ү т | t) | I | 





1 - filter("RN"»-1) 
2 - filter (ROWNUM<=10) 


6 - fi] T 





从 执行 计划 中 我 们 可 以 看 到 ， 两 条 SQL БЕТ index full scan， 第 一 条 SQL 从 索引 
中 扫描 了 72427 条 数据 (14-7 A-Rows=72427), 在 回 表 的 时 候 对 数据 进行 了 大 量 过 滤 (14-6), 
最 后 得 到 10 条 数据 ， 耗 费 了 1 273 个 逻辑 读 (Buffers=1273 )。 第 二 条 SQL 从 索引 中 扫描 了 10 
条 数据 ， 耗 费 了 5 个 逻辑 读 (Buffers=5)。 显 而 易 见 ， 第 二 条 SQL 的 执行 计划 是 正确 的 ， 而 第 
一 条 SQL 的 执行 计划 是 错误 的 ， 应 该 尽量 在 索引 扫描 的 时 候 就 取得 10 行 数据 。 

为 什么 仅仅 是 过 滤 条 件 不 一 样 ， 两 条 SQL 在 效率 上 有 这 么 大 区 别 呢 ?这 是 因为 第 一 条 
SQL 过 滤 条 件 是 owner='SCOTT' ，owner='SCOTT' 在 表 中 只 有 很 少数 据 ， 通 过 扫描 
object id 列 的 索引 ， 然 后 回 表 再 去 匹配 owner='SCOTT'， 因 为 owner='SCOTT' 数 据 量 少 ， 


139 


140 


a cS 


要 搜索 大 量 数据 才能 匹配 上 。 而 第 二 条 SQL 的 过 滤 条 件 是 owner='SYS'， 因 为 owner='SYS' 
数据 量 多 ， 只 需要 搜索 少量 数据 就 能 匹配 上 。 
想 要 优化 第 一 条 SQL， 就 需要 让 其 在 索引 扫描 的 时 候 读 取 少 量 数据 块 就 取得 10 行 数据 ， 
这 就 需要 将 过 滤 列 (owner) 包含 在 索引 中 ， 排 序列 是 object id， 那么 现在 我 们 创建 组 合 索引 。 
SQL> create index idx page ownerid оп t page(owner,object id); 


Index created. 


我 们 查看 强制 走 索 引 Cidx page ownerid) 带 有 A-Rows 的 执行 计划 (省 略 了 部 分 数据 )。 
SOL» select * from table(dbms xplan.display cursor(null,null, 'ALLSTATS LAST')); 


PLAN TABLE OUTPUT 
SOL ID algl6uafrO05qf, child number 0 
select * from (select * from (select а. =; rownum rn 
from (select /%% index(t page idx page ownerid) */ 
* from t "page 
where owner = 'SCOTT' order by 
object id) a) where rownum <= 10) where rn >= 1 





Plan hash value: 4175643597 


| Id [Operation | Name |Starts|E-Rows|A-Rows|Buffers| 
| 0 |SELECT STATEMENT | | 1| | 10| 6| 
|* 1 |VIEW I | El 10| 10| 61 
|* 2 | COUNT STOPKEY | | 1| | 10| 6| 
| 3 | МЕНИ | | LI 571 10| 6| 
je] СООТ | | 1| | 101 6| 
І» 45М VIEW | | 1| 57| 101 6| 
(| #6] TABLE ACCESS BY INDEX ROWID|T PAGE | 11 571 10| 6| 
|% 27,1 INDEX RANGE SCAN |IDX PAGE OWNERID| 1| 57| 101 3I 


1 - filter("RN"»-1) 
2- filter (ROWNUM«- 10) 
7 - access ("OWNER"-'SCOTT') 


从 执行 计划 中 我 们 可 以 看 到 ，SQL 走 了 索引 范围 扫描 ， 从 索引 中 扫描 了 10 条 数据 ， 一 共 
耗费 了 6 个 逻辑 读 。 这 说 明 该 执行 计划 是 正确 的 。 大 家 可 能 会 问 : 可 不 可 以 在 创建 索引 的 时 候 
将 object id 放 在 前 面 、owner 放 在 后 面 ? 现在 我 们 来 创建 另外 一 个 索引 ， 将 object id 列 放 在 
前 面 ，owner 放 在 后 面 。 


SQL» create index idx page idowner on t page(object id,owner); 





Index created. 


我 们 查看 强制 走 索 引 (dx page idowner) 带 有 A-Rows 的 执行 计划 (省 略 了 部 分 数据 )。 


l SQL» select * from table(dbms xplan.display cursor (null,null, 'ALLSTATS LAST')); 


select * from (select * from (select a.*, rownum rn 
from (select /** index(t page idz page idowner) */ > 
from t page where owner = 
'"SCOTT' order by object id) a) where 
rownum <= 10) where rn >= 1 





Plan hash value: 2811585238 


| SELECT STATEMENT 
| VIEW | 
| COUNT STOPKEY | 

VIEW 





TABLE ACCESS BY TNDEXTROWTD | T_PAGE 


1 - filter("RN"»-1) 
2 - filter (ROWNUM<=10) _ 
7 = access ("OWNER"="SCOTT") 
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PLAN TABLE OUTPUT 
врло A ehild.nunber D, у = ылайы Ж шу ук. 
filter ("ОЙМЕК"='5СОТТ') 
从 执行 计划 中 我 们 看 到 ，SQL 走 了 索引 全 扫描 ， 从 索引 中 扫描 了 10 条 数据 ， 但 是 索引 全 | 
扫描 耗费 了 221 个 逻辑 读 ， 因 为 要 边 扫描 索引 边 过 滤 数 据 〈owner='SCOTT')，SQL 一 共 耗 费 | 
了 224 个 逻辑 读 ， 与 走 object id 列 的 执行 计划 (耗费 了 1273 个 逻辑 读 ) 相 比 ， 虽 然 也 提升 了 
性 能 ， 但 是 性 能 最 好 的 是 走 idx page ownerid 这 个 索引 的 执行 计划 (逻辑 读 为 6)。 
大 家 可 能 还 会 问 ， 可 不 可 以 只 在 owner 列 创建 索引 呢 ? 也 就 是 说 不 将 排序 列 包含 在 索引 
中 。 如 果 过 滤 条 件 能 过 滤 掉 大 部 分 数据 (owner='SCoTT' )， 那 么 这 时 不 将 排序 列 包含 在 索 
引 中 也 是 可 以 的 ,因为 这 时 只 需要 对 少量 数据 进行 排序 , 少量 数据 排序 几乎 对 性 能 没有 什么 影 
响 。 但 是 如 果 过 滤 条 件 只 能 过 滤 掉 一 部 分 数据 ， 也 就 是 说 返回 数据 量 很 多 Cowner-'SYS'), 
这 时 我 们 必须 将 排序 列 包含 在 索引 中 ,如 果 不 将 排序 列 包 含 在 索引 中 , 就 需要 对 大 量 数据 进行 
排序 。 在 实际 生产 环境 中 ， 过 滤 条 件 一 般 都 是 绑 定 变量 ， 我 们 无 法 控制 传 参 究 竟 传 入 哪个 值 ， 
这 就 不 能 确定 返回 数据 究竟 是 多 还 是 少 ,所 以 为 了 保险 起 见 , 建议 最 好 将 排序 列 包含 在 索引 中 ! 
另外 要 注意 ， 如 果 排 序列 有 多 个 列 ， 创 建 索 引 的 时 候 ， 我 们 要 将 所 有 的 排序 列 包 含 在 索引 
中 ， 并 且 要 注意 排序 列 先后 顺序 (语句 中 是 怎么 排序 的 ， 创 建 索 引 的 时 候 就 对 应 排序 )， 而 且 
还 要 注意 列 是 升序 还 是 降序 。 如 果 分 页 语句 中 排序 列 只 有 一 个 列 , 但 是 是 降序 显示 的 , © Ж 
引 的 时 候 就 没 必要 降序 创建 了 ， 我 们 可 以 使 用 HINT: index desc 让 索引 降序 扫描 就 行 。 
现 有 如 下 分 页 语句 。 
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pu 


select * 
from (select * 
from (select a.*, rownum rn 
from (select * 
from t page 


order by object id, object name desc) a) 
where rownum «- 10) 
where rn »- 1; 


创建 索引 的 时 候 ， 只 能 是 object id 列 在 前 ，object_name 列 在 后 面 ， 另 外 object name 是 
降序 显示 的 ， 那 么 在 创建 索引 的 时 候 ， 我 们 还 要 指定 object name 列 降 序 排序 。 此 外 该 SQL 
没有 过 滤 条 件 ， 在 创建 索引 的 时 候 ， 我 们 还 要 加 个 常量 。 现 在 我 们 创建 如 下 索引 。 

SQL» create index idx page idname on t page(object id,object name desc,0); 


Index created. 


我 们 查看 强制 走 索 引 Gdx page idname) 带 有 A-Rows 的 执行 计划 省略 了 部 分 数据 )。 
SQL» select * from table (dbms_xplan.display_cursor(null,null,'ALLSTATS LAST')); 


PLAN TABLE OUTPUT 


select * from (select * from (select a.*, rownum rn 
from (select t page id де me) 
* 





order by object id, object name desc) a) where 
rownum <= 10) where rn >= 1 


Plan hash value: 445348578 


| Id |Operation | Name |Starts|E-Rows| A-Rows |Buffers| 
| 0 |SELECT STATEMENT | | 1l | 10 | 5] 
1* 1 | VIEW | | 1| 10| 10 | a) 
I* 2 | COUNT STOPKEY | | 1| | 10 | 5! 
[кд УТЕЙ | | 1| 61800| 10 | 51 
{ 1461 COUNT | | 1| | 10 | 51 
k il VIEW | 1| 61800| 10 | 5| 
77671 TABLE ACCESS BY INDEX ROWID|T PAGE | 1| 61800| 10 | 5| 
ы 7207 | INDEX FULL 5САМ |IDX PAGE IDNAME| 1| 61800| 10 | 3| 


1 - filter("RN"»-1) 
2 - filter (ROWNUM«-10) 


如 果 创 建 索 引 的 时 候 将 object name WEA, object id 放 在 后 面 ， 这 个 时 候 ， 索 引 中 列 
先后 顺序 与 分 页 语句 中 排序 列 先后 顺序 不 一 致 ， 强 制 走 索 引 的 时 候 ， 执 行 计划 中 会 出 现 SORT 
ORDER BY 关键 字 。 因 为 索引 的 顺序 与 排序 的 顺序 不 一 致 ， 所 以 需要 从 索引 中 获取 数据 之 后 
再 排序 ， 有 排序 就 会 出 现 SORT ORDER BY。 现 在 我 们 创建 如 下 索引 。 


і SQL» create index idx page nameid on t раде (орјесё пате, орјесі іа, 0); 
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| Index created. 


现在 查看 强制 走 索 引 〈idx_page_nameid) 带 有 A-Rows 的 执行 计划 《〈 和 省 略 了 部 分 数据 )。 
SQL» select * from table(dbms xplan.display cursor(null,null, 'ALLSTATS LAST')); 


PLAN TABLE OUTPUT 


501 ID 28b8nwayah0z68, child number 0 
select * from (select * 


from (select 
* 


from (select a.*, rownum rn 









from t page | 
order by object id, object name desc) a) where rownum «- 
10) where rn >= 1 


Plan hash value: 2869317785 


























Id |Operation Name Starts|E-Rows 
0 |SELECT STATEMENT 1| 
ый! VIEW 1| 10 
072 COUNT STOPKEY | W | 
a" | VIEW | | 11 61600] 
4 COUNT | 1| 
5 VIEW | 1| 61800 
6 1| 61800 
7 TABLE ACCESS BY INDEX ROWID|T PAGE 1| 61800 
8 INDEX FULL SCAN IDX PAGE NAMEID 1| 61800| 








Predicate Information (identified by operation id): 


1 = filter("RN"»-1) 
2 - filter (ROWNUM«-10) 


如 果 创 建 索 引 的 时 候 没有 指定 object name 列 降序 排序 ， 那 么 执行 计划 中 也 会 出 现 SORT 
ORDER BY。 因 为 索引 中 排序 和 分 页 语句 中 排序 不 一 致 。 现 在 我 们 创建 如 下 索引 。 


SQL» create index idx page idnamel on t page(object id,object name,0); 


Index created. 


我 们 查看 强制 走 索 引 Cidx page idnamel) WA A-Rows 的 执行 计划 (省 略 了 部 分 数据 )。 
SQL> select * from table (dbms xplan.display cursor(null,null, 'ALLSTATS LAST')); 


PLAN TABLE OUTPUT 


SQL ID 2dsmtc9b65a7v, child number 0 
select * from (select * from (select a.*, rownum rn 


from (select 
* 





from t page 
order by object id, object name desc) a) where rownum <= 
10) where rn >= 1 


Plan hash value: 170538223 
143 

















144 


®8ж= 调 优 技巧 
| Id lOperation | Name IStarts|E-Rows |A-Rows | Buffers | 
| 0 |SELECT STATEMENT | | 1| | 10| 1533| 
|* 1 | VIEW | | 1| 10| 10| 1533| 
|* 2 | COUNT STOPKEY | | 1| | 101 1533] 
| 3]| VIEW | | 1| 61800| 10| 1533] 
{ =A COUNT | | 1| | 101 15331 
222) VIEW | | 1| 618001 10|- 15331 
| р! SORT ORDER BY | | 1| 61800| 101 1533] 
7-1 TABLE ACCESS BY INDEX ROWID|T PAGE | 1| 61800| 72608| 1533| 
im 2851 INDEX FULL SCAN |IDX PAGE IDNAME1| 11 618001 72608| 430| 


1 - filter("RN"»-1) 
2 - filter (ROWNUM<=10) 


分 页 语句 中 如 果 出 现 了 SORT ORDER BY, 这 就 意味 着 分 页 语句 没有 利用 到 索引 已 经 排序 
的 特性 ， 执 行 计 划一 般 是 错误 的 ， 这 时 需要 创建 正确 的 索引 。 

现 有 如 下 SQL (注意 ， 过 滤 条 件 有 等 值 条 件 ， 也 有 非 等 值 条 件 ， 当 然 也 有 order by), I 
在 要 将 查询 结果 分 页 显示 ， 每 页 显示 10 条 。 


| select * from t page where owner = 'SYS' and object id > 1000 order by object name; 


大 家 请 思考 ,应 该 怎么 创建 索引 ， 从 而 优化 上 面 的 分 页 语句 呢 ? 上 文 提 到 ， 如 果 分 页 语 名 
中 有 排序 列 ， 创 建 索引 的 时 候 ， 要 将 排序 列 包 含 在 索引 中 。 所 以 现在 我 们 只 需要 将 过 滤 列 
owner. object id 以 及 排序 列 object name 组 合 起 来 创建 索引 中 即 可 。 

因为 owner 是 等 值 过 滤 ，object id 是 非 等 值 过 滤 ， 创 建 索引 的 时 候 ， 我 们 要 优先 将 等 值 过 
滤 列 和 排序 列 组 合 在 一 起 ， 然 后 再 将 非 等 值 过 滤 列 放 到 后 面 。 


SQL» create index idx ownernameid on t page (Owner,óobject name,object id); 





Index created. 


让 我 们 查看 强制 走 索 引 〈idx_ownernameid) 带 有 A-Rows 的 执行 计划 (省 略 了 部 分 数据 )。 
SQL» select * from table(dbms xplan.display cursor(null,null,'ALLSTATS LAST')); 


PLAN TABLE OUTPUT 





select * from (select * fron (select a.*, rownum rn 
from (select /** index(t page idx ownernameid) */ 
* from t page 
where owner - 'SYS' and object id » 
1000 order by object name) a) where 


rownum <= 10) where rn >= 1 
Plan hash value: 2090516350 
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Id |Operation Name Starts|E-Rows| A-Rows |Buffers 
0 |SELECT STATEMENT 11 10 14 
1 VIEW 11 10 10 14 
2 COUNT STOPKEY il 10 14 
3 VIEW 1| 26937 10 14 
4 COUNT 1 10 14 
5 VIEW 1| 26937 10 14 
6 TABLE ACCESS BY INDEX ROWID|T PAGE 11 26937 10 14 
ж 7] INDEX RANGE SCAN IDX OWNERNAMEID 1 254 10 4 


1 — filter("RN">=1) 

2 - filter (ROWNUM<=10) 

7 - access("OWNER"-'SYS' AND "OBJECT 1р">1000) 
filter("OBJECT 1р">1000) 


执行 计划 中 没有 SORT ORDER BY， 逻 辑 读 也 才 14 个 ， 说 明 执 行 计划 非常 理想 。 也 许 大 
家 会 问 ， 为 何不 创建 如 下 这 样 索 引 呢 ? 
SQL> create index idx owneridname on t page (owner,object id,object name); 


Index created. 


我 们 碍 看 强制 走 索引 Сах owneridname) 带 有 A-Rows 的 执行 计划 省略 了 部 分 数据 )。 
SQL» select * from table(dbms xplan.display cursor(null,null, 'ALLSTATS LAST')); 


PLAN TABLE OUTPUT 


SQL ID 7bm9sf2u94uxa, child number 0 






select * from (select * from (select a.*, rownum rn 
from (select Й inde» page idx 
* from t page 
where owner - 'SYS' and object id » 
1000 order by object name) a) where 


rownum <= 10) where rn >= 1 


Plan hash value: 2498002320 





















| Id |Operation | Name 

| 0 ISELECT STATEMENT | 

|* 1 | VIEW | 

1*2 |. COUNT STOPKEY | 

з, | VIEW | 

(ЗДІ COUNT | 

|, а VIEW | 

Pren SORT ORDER BY | 

| Tal TABLE ACCESS BY INDEX ROWID|T PAGE 

je em INDEX RANGE SCAN | IDX OWNERIDNAME | 


Predicate Information (identified by operation id): 
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Goode D; u тас S. 


1 - filter("RN"»21) 
2 - filter (ROWNUM«-10) 
8 - access("OWNER"-'SYS' AND "OBJECT ID"21000 AND "OBJECT ID" IS NOT NULL) 


该 执行 计划 中 有 SORT ORDER BY, 说 明 没有 用 到 索引 已 经 排序 特性 , 而 且 罗 辑 读 为 002 
个 ,这 说 明 该 执行 计划 是 错误 的 。 为 什么 该 执行 计划 是 错误 的 呢 ? 这 是 因为 该 分 页 语句 是 根据 
object name 进行 排序 的 ， 但 是 创建 索引 的 时 候 是 按照 owner. object id. object name 顺序 创 
建 索引 的 ， 索 引 中 前 5 条 数据 如 下 。 


SOL» select * 
2 from (select rownum rn, owner, object id, object name 








1 SYS 1001 NOEXP$ 
2 ЗҮ 1002 EXPPKGOBJS$ 
3 sys 1003 I OBJTYPE 
m  EXPPKGACTS 
I ACTPACKAGE 


在 这 前 5 条 数据 中 ， 我 们 按照 分 页 语句 排序 条 件 object name 进行 排序 ， 应 该 是 第 4 行 数 
据 显示 为 第 一 行 数据 ,但 是 它 在 索引 中 排 到 了 第 4 行 , 所 以 索引 中 数据 的 顺序 并 不 能 满足 分 页 
语句 中 的 排序 要 求 , 这 就 产生 了 SORT ORDER BY 进而 导致 执行 计划 错误 ,为 什么 按照 owner、 
object name. object id 顺序 创建 索引 ， 执 行 计 划 是 对 的 呢 ? 现在 我 们 取 索 引 中 前 5 条 数据 。 


SQL> select * 
from (select rownum rn, owner, object_id, object_name 


- осу G > Q № 





1 SYS 34042 /1000323d DelegateInvocationHa 
2 SYS 44844 /1000е8а1 LinkedHashMapValueIt 
3 SYS 23397 /1005bd30 LnkdConstant 

4 SYS 19737 /10076b23 OraCustomDatumClosur 
5 SYS 45460 /100c1606 StandardMidiFileRead 


索引 中 的 数据 顺序 完全 符合 分 页 语句 中 的 排序 要 求 ， 这 就 不 需要 我 们 进行 SORT ORDER 
BY 了 ， 所 以 该 执行 计划 是 对 的 。 

现在 我 们 继续 完善 分 页 语句 的 优化 思路 : 如 果 分 页 语句 中 有 排序 (order by)， 要 利用 索引 
已 经 排序 特性 ， 将 order by 的 列 按照 排序 的 先后 顺序 包含 在 索引 中 ， 同 时 要 注意 排序 是 升序 还 
是 降序 。 如 果 分 页 语句 中 有 过 滤 条 件 ， 我 们 要 注意 过 滤 条 件 是 否 有 等 值 过 滤 条 件 ， 如 果 有 等 值 
过 滤 条 件 ， 要 将 等 值 过 滤 条 件 优先 组 合 在 一 起 ， 然 后 将 排序 列 放 在 等 值 过 滤 条 件 后 面 ， 最 后 将 
非 等 值 过 滤 列 放 排 序列 后 面 。 如 果 分 页 语句 中 没有 等 值 过 滤 条 件 , 我 们 应 该 先 将 排序 列 放 在 索 
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引 前 面 ,将 非 等 值 过 滤 列 放 后 面 , 最 后 利用 rownum If COUNT STOPKEY 特性 来 优化 分 页 SQL。 
如 果 分 页 中 没有 排序 ， 可 以 直接 利用 rownum 的 COUNT STOPKEY .特性 来 优化 分 页 SQL. 
如 果 我 们 想 一 眼看 出 分 页 语句 执行 计划 是 正确 还 是 错误 的 ， 先 看 分 页 语句 有 没有 ORDER 
BY， 再 看 执行 计划 有 没有 SORT ORDER BY， 如 果 执 行 计划 中 有 SORT ORDER BY， 执 行 计 
划一 般 都 是 错误 的 。 
请 大 家 思考 ， 如 下 分 页 语句 应 该 如 何 建 立 索 引 〈 提 示 : 该 SQL 没有 等 值 过滤 ) ? 


select * 
from (select * 
from (select a.*, rownum гп 
from (select * 
from 
where | 
and 
order 
where rownum «- 10) 
where rn >= 1; 


如 果 分 页 语句 中 排序 的 表 是 分 区 表 , 这 时 我 们 要 看 分 页 语句 中 是 否 有 跨 分 区 扫描 ,， 如果 有 
跨 分 区 扫描 , 创建 索引 一 般 都 创建 为 global 索引 ， 如 果 不 创建 global 索引 ， 就 无 法 保证 分 页 的 
顺序 与 索引 的 顺序 一 致 。 如 果 就 只 扫描 一 个 分 区 ， 这 时 可 以 创建 local 索引 。 

现在 我 们 创建 一 个 根据 object id 范围 分 区 的 分 区 表 р test 并 且 插入 测试 数据 。 


SQL> create table p_test( 
2 OWNER VARCHAR2 (30), 
3 ОВСЕСТ МАМЕ VARCHAR2 (128), 
4  SUBOBJECT NAME VARCHAR2 (30), 
5 OBJECT ID NUMBER, 
6 
7 
8 







DATA OBJECT ID NUMBER, 
OBJECT TYPE VARCHAR2 (19), 


CREATED DATE, 
9 LAST DDL TIME РАТЕ, 
10 TIMESTAMP VARCHAR2 (19), 
11 STATUS VARCHAR2 (7), 
12 TEMPORARY VARCHAR2 (1), 
13 GENERATED VARCHAR2 (1), 
14 SECONDARY VARCHAR2 (1), 
15 NAMESPACE NUMBER, 
16 EDITION NAME VARCHAR2 (30) 
17 ) partition by range (object id) 


18! $4 

19 partition pl values less than (10000), 
20 partition p2 values less than (20000), 
21 partition p3 values less than (30000), 
22 partition p4 values less than (40000), 
23 partition p5 values less than (50000), 
24 partition p6 values less than (60000), 
25 partition p7 values less than (70000), 
26 partition p8 values less than (80000), 
27 partition pmax values less than (maxvalue) 
28 ); 


Table created. 


SQL» insert into p test select * from dba objects; 
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72662 rows created. 


SQL> commit; 


现 有 如 下 分 页 语句 (根据 范围 分 区 列 排序 )。 


select * 
from (select * 
from (select a.*, rownum rn 
from (select * from p test Ord 
where rownum «- 10) 
where rn »- 1; 


该 分 页 语句 没有 过 滤 条 件 ， 因 此 会 扫描 表 中 所 有 分 区 。 因 为 排序 列 恰好 是 范围 分 区 列 ， 范 
围 分 区 每 个 分 区 的 数据 也 是 递增 的 ， 这 时 我 们 创建 索引 可 以 创建 为 local 索引 。 但 是 如 果 将 范 
围 分 区 改 成 LIST 分 区 或 者 HASH 分 区 ， 这 时 我 们 就 必须 创建 global 索引 ， 因 为 LIST 分 区 和 
HASH 分 区 是 无 序 的 。 

现在 我 们 创建 local 索引 。 


SQL» create index idg ptest id on р test (орјесі id,0) local; 







есі dd) a) 


2] 


Index created. 


我 们 查看 强制 走 索 引 ,(idx_ptest_ id) 带 有 A-Rows 的 执行 计划 省略 了 部 分 数据 )。 


SQL» select * from table (dbms xplan.display cursor(null,null,'ALLSTATS LAST')); 


PLAN TABLE OUTPUT 


select * from (select * 
from (select / 

* from p test 
order by object id) a) where rownum <= 10) where rn >= 1 


from (select *, rownum rn 





Plan hash value: 1636704844 

















| Id |Operation Name | Starts | E-Rows | A- Rows | Buffers 
0 |SELECT STATEMENT | T 10| 5| 

е m VIEW | 1 10 10| 51 
ж £g COUNT STOPKEY | 1 10| 5| 
3 VIEW | 1| 51888 10| 51 

4 COUNT | 1 | 10| 5 

5 VIEW | 1| 51888 10| 5| 

6 PARTITION RANGE ALL | 1| 51888 10| 5) 

m TABLE ACCESS BY LOCAL INDEX ROWID|P TEST | 1| 51888 10| 5 | 

8 | INDEX FULL SCAN IDX PTEST ID| 1| 51888 ДЮ | 3| 


1 = filter ("RN">=1) 
2 - filter (ROWNUM<=10) 
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现 有 如 下 分 页 语句 (根据 object name 排序 )。 


select * 
from (select * 
from (select a.*, rownum rn 
from (select * from p test order by object name) a) 
where rownum <= 10) 
where rn »- 1; 


这 时 我 们 就 需要 创建 global 索引 ， 如 果 创 建 local 索引 会 导致 产生 SORT ORDER BY. 


SOL» create index idx ptest name on p test(object name,0) local; 


Index created. 


现在 查看 强制 走 索 引 Cidx ptest name) 带 有 A-Rows 的 执行 计划 (省 略 了 部 分 数据 )。 


SOL» select * from table (dbms xplan.display cursor(null,null, 'ALLSTATS LAST')); 


PLAN TABLE OUTPUT 


select * from (select * 
from (select 
* 






from p test 
order by object name) a) where rownum «- 10) where rn »-1 


Plan hash value: 2548872510 





| Id |Орегағтіоп | Name |Starts|E-Rows|A-Rows|Buffers | 
| 0 |SELECT STATEMENT | | 1| | 10| 
|* 1 | VIEW | | 1| 10| 10| 
|* 2 | COUNT STOPKEY | | 11 | 101 
| 3]| VIEW | | 11 51888| 101 
| 3484 COUNT | | 1| | 10| 
|7 57) VIEW | 1 1| 51888| 10| 
| 41 SORT ORDER BY | | 1| 51888] 101 
Ü-] PARTITION RANGE ALL | | 1| 51888| 72662| 
| 8! TABLE ACCESS BY LOCAL INDEX ROWID|P TEST | 9| 51888] 226602 | 
ШЕЛ! INDEX FULL 5САМ |IDX PTEST NAME| 9| 51888| 72662| 


1 = filter("RN"»-1) 
2 - filter (ROWNUM<=10) 


现在 我 们 将 索引 ідх ptest name 重建 为 global 索引 。 
SQL> drop index idx ptest name; 
Index dropped. 
SOL» create index idx ptest name on p test(object name,0); 


Index created. 
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查看 强制 走 索引 (ах ptest пате) 带 有 A-Rows 的 执行 计划 《〔〈 和 省 略 了 部 分 数据 )。 


SQL> select * from table (dbms_xplan.display_cursor (null,null,'ALLSTATS LAST')); 


PLAN TABLE OUTPUT 


SQL ID 50hgw72gnvs83, child number 0 


select * from (select * from (select a.*, rownum rn 
from (select /%% index(p test idx ptest name) */ 
* from p test 
order by object name) a) where rownum «- 10) where rn »-1 


Plan hash value: 4135902528 




















Id |Operation Name Starts |E-Rows | A-Rows | Buffers 
0 |SELECT STATEMENT | 1| | 10 
> L VIEW 1 10| 10| 
* 2 COUNT STOPKEY 1 | 10 
3 VIEW 1| 51888| 10 
4 COUNT | 1| | 10 
© | VIEW 1| 518881 10| 
6 TABLE ACCESS BY GLOBAL INDEX ROWIDI|P TEST | 1| 51888| 10 
7 INDEX FULL SCAN IDX PTEST NAME 1| 51888| 4 





Predicate Information (identified by operation id): 


l — filter("RN"»z1) 
2 - filter (ROWNUM«-10) 


832 ”多 表 关 联 分 页 优化 思 


多 表 关 联 分 页 语句 ， 要 利用 索引 已 经 排序 特性 、ROWNUM 的 COUNT STOPKEY 特性 以 
及 峰 套 循环 传 值 特性 来 优化 。 

现在 我 们 创建 男 外 一 个 测试 表 T_PAGE2。 

SQL> create table t page2 as select * from dba objects; 


Table created. 


现 有 如 下 分 页 语句 。 


select * 
from (select * 
from (select a.owner, 

a.object_id, 

a.subobject_name, 

a.object_name, 

rownum rn 

from.(select tl.owner, 
tl.object id, 
tl.subobject name, 
t2.0bject name 
from t page tl, t page2 t2 
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8.3 分 页 语句 优化 思路 


where tl.object id = t2.object id 
order by t2.object_name) a) 
where rownum <= 10) 
where rn >= 1; 


分 页 语句 中 排序 列 是 t page2 的 object name， 我 们 需要 对 其 创建 一 个 索引 。 
SOL» create index idx page2 name on t page2(object name,0); 


Index created. 


现在 强制 t page2 ЖИИ CERS HRE AREMARK, t page TEAM CES RH 
被 驱动 表 ， 利 用 rownum 的 COUNT STOPKEY 特性 ， 扫 描 到 10 条 数据 ，SQL 就 停止 。 现 在 
我 们 查看 强制 走 索 引 ， 强 制 走 典 套 循 环 的 A-ROWS 执行 计划 。 


SQL» select * from table (dbms_xplan.display_cursor (null,null,'ALLSTATS LAST')); 


PLAN TABLE OUTPUT 


select * from (select * from (select 

a.owner,a.object id,a.subobject name,a. object | name, EOE rn 
from (select WP ead 

tl.owner,tl.object id,tl. subobject _ name, t2. object | name 








from t page tl, t page2 t2 where 
tl.object id - t2.0bject id order by 
t2.0bject name) a) where rownum «- 10) where rn »- 1 


Plan hash value: 4182646763 





| Id |Operation | Name Starts|E-Rows|A-Rows| Buffers 
| 0 [SELECT STATEMENT | | 1| | 10| 29 | 
|* 1 | VIEW | | 11 10| 10| 29 | 
|* 2 | COUNT STOPKEY | 11 | 101 29 | 
| 31 VIEW | 1| 61800| 10| 29 | 
E COUNT | | 1| | 10| 29 | 
(2571 VIEW | | 1| 61800| 10| 29 | 
| ӨЗДІ NESTED LOOPS | 1| 61800] 10| 29 | 
| 1%1 TABLE ACCESS BY INDEX ROWID|T PAGE2 | 1| 66557] 10| 10 | 
[В | INDEX FULL SCAN |IDX PAGE2 МАМЕ | 1| 66557| 10| 4 | 
| 9| TABLE ACCESS BY INDEX ROWID|T PAGE 10| i] 10| 19 | 
|*10 | INDEX RANGE SCAN |IDX PAGE 10| Li 10| 13 | 


1 - filter("RN"»-1) 
2 - filter(ROWNUM«-10) 
10 ~ access("Tl"."OBJECT ID"-"T2"."OBJECT ID") 


从 执行 计划 B|, 扫描 了 10 行 数据 , 传 值 10 次 给 被 
驱动 表 , 然后 SQL 停止 运行， 逻辑 读 一 共 29 个 , 该 执行 计划 是 正确 的 , 而 且 是 最 佳 执 行 计划 。 
大 家 思考 一 下 ， 对 于 上 面 的 分 页 语句 ， 能 否 走 HASH 连接 ? ШЖ SQL 走 了 HASH 连接 ， 
这 时 两 个 表 关 联 之 后 得 到 的 结果 无 法 保证 是 有 序 的 ， 这 就 需要 关联 完成 后 再 进行 一 次 排序 





151 





152 


(SORT ORDER BY)， 所 以 不 能 走 HASH 连接 ， 同 理 也 不 能 走 排 序 合 并 连接 。 

为 什么 多 表 关 联 的 分 页 语句 必须 走 骨 套 循环 呢 ? 这 是 因为 插 套 循环 是 驱动 表 传 值 给 被 驱 
动 表 ,如 果 了 驱动 表 返 回 的 数据 是 有 序 的 ， 那么 关联 之 后 的 结果 集 也 是 有 序 的 ， 这 样 就 可 以 消除 
SORT ORDER BY. 

现 有 如 下 分 页 语句 〈 排 序列 来 自 两 个 表 )。 


select * 
from (select * 
from (select a.owner, 
.object id, 
.subobject name, 
.object name, 
rownum rn 
from (select tl.owner, 
tl.object id, 
tl.subobject name, 
t2.0bject name 
from t page tl, t page2 t2 
where tl.object id = t2.0bject id 
order by t2.0bject name ,tl.subobject name) a) 
where rownum «- 10) 
where rn >= 1; 


因为 以 上 分 页 语句 排序 列 来 自 多 个 表 , 这 就 需要 等 两 表 关 联 完 之 后 再 进行 排序 ， 这 样 无 法 
消除 SORT ORDER BY， 所 以 以 上 SQL 语句 无 法 优化 ， 两 表 之 间 也 只 能 走 HASH ЖЖ. ШЖ 
想 优 化 上 面 分 页 语句 ,我 们 可 以 与 业务 沟通 ， 去掉 一 个 表 的 排序 列 ， 这 样 就 不 需要 等 两 表 关联 
完 之 后 再 进行 排序 。 

现 有 如 下 分 页 语句 (根据 外 连接 从 表 排 序 )。 


select * 
from (select * 
from (select a.owner, 
a.object id, 
a.subobject name, 
a.object name, 
rownum rn 
from (select tl.owner, 
tl.object id, 
tl.subobject name, 
t2.0bject name 
from t page tl left join t page2 t2 
on tl.object id - t2.object id 
order by t2.0bject name) а) 
where rownum «- 10) 
where rn »- 1; 


РЯ ЖАКОШ 8, РАЛ ИК ЕО ТЕ ЕКІН, "ze Heise do. XX BE 
KÆ tl, 但 是 排序 列 来 自 世 , 在 分 页 语句 中 , 对 哪个 表 排 序 , ЛУЫН РЕ RS AIR PIG] Ж. 
但 是 这 里 相互 了 矛盾。 所 以 该 分 页 语句 无 法 优化 ，tl 与 0 RAEE HASH 连接 。 如 果 想 要 优化 以 
上 分 页 语句 ， 我 们 只 能 让 ti 表 中 的 列 作为 排序 列 。 

分 页 语句 中 也 不 能 有 distinct. group by, max, min, avg, union, union all 等 关键 字 。 因 
为 当 分 页 语句 中 有 这 些 关键 字 , 我 们 需要 等 表 关联 完 或 者 数据 都 跑 完 之 后 再 来 分 页 ， 这 样 性 能 
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84 使 用 分 析 函 数 优化 自 连接 


很 差 。 

最 后 , 我 们 总 结 一 下 多 表 关 联 分 页 优化 思路 。 多 表 关 联 分 页 语句 ， 如 果 有 排序 ， 只 能 对 其 
中 一 个 表 进 行 排序 ,让 参与 排序 的 表 作 为 嵌 套 循环 的 驱动 表 , 并 且 要 控制 驱动 表 返 回 的 数据 顺 
序 与 排序 的 顺序 一 致 ， 其 余 表 的 连接 列 要 创建 好 索引 。 如 果 有 外 连接 ,我们 只 能 选择 主 表 的 列 
作为 排序 列 ， 语 句 中 不 能 有 distinct, group Ьу, тах. тїп, avg. union, union all， 执 行 计划 
中 不 能 出 现 SORT ORDER BY. 


现 有 如 下 SQL 及 其 执行 计划 。 
SQL> select ename,deptno,sal 


2 from emp a 
3 where sal = (select max(sal) from emp b where a.deptno = b.deptno); 









Execution Plan 


Plan hash value: 1245077725 


| Та | Operation | Name | Rows | Bytes | Cost (%CPU)| Time 

| 0 | SELECT STATEMENT | | i. | 39 | 8 (25)1 00:00:01 
I* 1 | HASH JOIN | | radi 39 | 8 (25)! 00:00%01 | 
| 2] VIEW | УИ SQ 1 | 32 | 78 | 4 (25) | 00:00:01 

| З l HASH GROUP BY | | 3 | 21 | 4 (25)| 00:00:01 | 
| 4 | TABLE ACCESS FULL| EMP | 14 | 98 | 3 (0) | 00:00:01 

| ° | TABLE ACCESS FULL | EMP | 147) 182 | 3 (0) | 00:00:01 | 


1 - access ("SAL"="MAX(SAL)" AND "A"."DEPTNO"-"ITEM 1") 


该 SQL 表示 查询 员工 表 中 每 个 部 门 工 资 最 高 的 员工 的 所 有 信息 ， 访 问 了 EMP RAK. 
我 们 可 以 利用 分 析 函 数 对 上 面 SQL 进行 等 价 改写 ， 使 EMP 只 访问 一 次 。 
分 析 函 数 的 写法 如 下 。 


SQL> select ename, deptno, sal 
2 from (select a.*, max(sal) over(partition by deptno) max sal from emp a) 
3 where sal - max sal; 


Execution Plan 


Plan hash value: 4130734685 


0 | SELECT STATEMENT | | | | 4 (25)1 00:00:01 | 

1 | VIEW | | | | 4 (25)| 00:00:01 | 
| 2 WINDOW SORT | | 14 | 182 | 4 (25)| 00:00:01 | 

3 | TABLE ACCESS FULL| EMP | | | 3 (0)| 00:00:01 
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BEER o мышы 


1- filter("SAL"-"MAX SAL") 


使 用 分 析 函 数 改 写 之 后 ， 减 少 了 表 扫 描 次 数 ，EMP 表 越 大 ， 人 性 能 提升 越 明 显 。 


ee 






A 


现 有 如 下 SQL. 


І select % from a,b where a.object id-b.object id; 


表 a 有 30MB， 表 b 有 30GB， 两 表 关 联 后 返回 大 量 数据 ， 应 该 走 HASH 连接 ， 因 为 a 是 
小 表 所 以 a 应 该 作为 HASH JOIN 的 驱动 表 , 大 表 b 作为 HASH JOIN 的 被 驱动 表 。 在 进行 HASH 
JOIN 的 时 候 ， 豫 动 表 会 被 放 到 PGA 中 ， 这 里 ， 因 为 驱动 表 a 只 有 30MB, РСА 能 够 完全 容纳 
下 驱动 表 。 因 为 被 驱动 表 b 特别 大 ， 想 要 加 快 SQL 查询 速度 ， 必 须 开启 并 行 查询 。 超 大 表 与 
超 小 表 在 进行 并 行 HASH 连接 的 时 候 ， 可 以 将 小 表 ( 驱 动 表 ) 广播 到 所 有 的 查询 进程 ， 然 后 
对 大 表 进 行 并 行 随 机 扫描 ， 每 个 查询 进程 查询 部 分 b 表 数 据 ， 然 后 再 进行 关联 。 假 设 对 以 上 
SQL 启用 6 个 并 行进 程 对 a 表 的 并 行 广播 ， 对 b 表 进 行 随机 并 行 扫 描 《〈 每 部 分 记 为 
bl,b2,b3,b4,bS,b6) 其 实 就 相当 于 将 以 上 SQL 内 部 等 价 改写 为 下 面 SQL. 


select * from a,bl where a.object id-bl.object id  --- 并 行进 行 
union all 
select * from a,b2 where a.object_id=b2.object_id  --- 并 行进 行 
union all 
select * from a,b3 where a.object id=b3.object іа =-= 并 行进 行 
union all 
select * from a,b4 where a.object id-b4.object id  --- 并 行进 行 
union all 
select * from a,b5 where a.object id-b5.object id ~--- 并 行进 行 
union all 
select * from a,b6 where a.object id-b6.object id; --- 并 行进 行 
怎么 才能 让 a 表 进 行 广播 呢 ? 我 们 需要 添加 hint: pq distribute (驱动 表 none, 
broadcast), 


现在 我 们 来 查看 a 表 并 行 广播 的 执行 计划 (为 了 方便 排版 ， 执 行 计划 中 省 略 了 部 分 数据 )。 


SQL> explain plan for select 
са11е1(6) use hash(a,b) ра distribute(a none,broadcast) */ 





3 from a, b 
4 where a.object id - b.object id; 


Explained. 
SQL» select * from table(dbms xplan.display); 


PLAN TABLE OUTPUT 
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86 超大 表 与 超大 表 关 联 优化 方法 


Plan hash value: 3536517442 


























Id | Operation Name Rows Bytes |IN-OUT| PQ Distrib 

0 SELECT STATEMENT 5064K| 1999М | 

| 1 PX COORDINATOR 

| e 7 PX SEND QC (RANDOM) | :Т010001 5064K 1999M| P->S QC (RAND) 

кєз HASH JOIN 5064K| 1999М| PCWP 
4 PX RECEIVE 74893 14М| PCWP | | 
5 PX SEND BROADCAST :TQ10000 | 74893 14M| Р->Р | BROADCAST | 

| 6 | PX BLOCK ITERATOR | 74893 14M| PCWC 

| qu TABLE ACCESS FULL| A 74893 14M| PCWP 

| 8. | PX BLOCK ITERATOR 5064K| 999M| PCWC | | 
9 TABLE ACCESS FULL B 5064K| 999M| PCWP | | 


3 — access("A"."OBJECT ID"-"B"."OBJECT ID") 


如 果 小 表 进 行 了 广播 ， 执 行 计划 Operation 会 出 现 PX SEND BROADCAST 关键 字 ，PQ 
Distrib 会 出 现 BROADCAST 关键 字 。 注 意 : 如 果 是 两 个 大 表 关 联 ， 干 万 不 能 让 大 表 广 播 。 


t тайы еі Mes 7537 UN s emn ES а қ, T X v 
2 i ZH — , " - b a = ЖР); 
E 1 — T. ы ' zl b Em A E 4 
KH A, AX. —J Ка J; Ь 7. a 

““”- ' P { „ 4 4 : 


现 有 如 下 SQL. 


| select * from a,b where a.object id-b.object id; 


Kat 4GB, X b 有 6GB， 两 表 关 联 后 返回 大 量 数据 ， 应 该 走 HASH 连接 。 因 为 a 比 b 
小 , 所 以 a 表 应 该 作为 HASH JOIN 的 驱动 表 。 驱 动 表 a 有 4GB, 需要 放 入 PGA 中 。 因 为 РСА 
中 work area 不 能 超过 2G， 所 以 PGA 不 能 完全 容纳 下 驱动 表 ， 这 时 有 部 分 数据 会 溢出 到 磁盘 
(TEMP) 进行 on-disk hash join。 我 们 可 以 开启 并 行 查询 加 快 查询 速度 。 超 大 表 与 超大 表 在 进 
行 并 行 HASH 连接 的 时 候 ， 需 要 将 两 个 表 根 据 连 接 列 进行 HASH 运算 ， 然 后 将 运算 结果 放 到 
РСА 中 ， 再 进行 HASH 连接 ， 这 种 并 行 HASH 连接 就 叫 作 并 行 HASH HASH 连接 。 假 设 对 上 
ІН SQL 启用 6 个 并 行 查询 ，a 表 会 根据 连接 列 进行 HASH 运算 然后 拆 分 为 6 份 ， 记 为 al，a2， 
a3, a4, a5, аб, b 表 也 会 根据 连接 列 进行 HASH 运算 然后 拆 分 为 6 份 ， 记 为 b1，b2，b3，b4， 
b5，b6。 那 么 以 上 SQL 开启 并 行 就 相当 于 被 改写 成 如 下 SQL. 





select * from al,bl where al.object id-bl.object id --- 并 行进 行 
union all 
select * from a2,b2 where a2.0bject id-b2.0bject id --- жб 
union all 
select * from a3,b3 where a3.object id-b3.object id -=-- 并 行进 行 
union all 
select * from a4,b4 where a4.0bject id-b4.0bject id -=-- 并 行进 行 
union all 
select * from a5,b5 where a5.object_id=b5.object_id --- 并 行进 行 
union all 
select * from a6,b6 where a6.0bject id-b6.0bject id; =--- 并 行进 行 
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Г 777 Kum 
对 于 上 面 SQL， 开 启 并 行 查 询 就 能 避免 on-disk hash join， 因 为 表 不 是 特别 大 ， 而 且 被 拆 
分 到 内 存 中 了 。 怎 么 写 HIT 实现 并 行 HASH HASH WE? 我 们 需要 添加 hint: 
pq_distribute〔 被 驱动 表 hash,hash )。 
现在 我 们 来 查看 并 行 HASH HASH 的 执行 计划 (为 了 方便 排版 ， 执 行 计划 中 省 略 了 部 分 
数据 )。 


SQL» explain plan for select 
/** parallel(6) use hash(a,b) pq distrib 
2 * 





ute (b hash,hash) */ 
3 from a, b 
4 where a.object_id = b.object id; 

Explained. 


SQL» select * from table(dbms xplan.display); 


PLAN TABLE OUTPUT 


Plan hash value: 728916813 





| Id | Operation | Name | Rows | Bytes |TempSpc|IN-OUT|PQ Distrib| 
0 | SELECT STATEMENT | | 3046M| 1174G| | | | 
| 1 | PX COORDINATOR | | | | | | | 
|; RT PX SEND ОС (RANDOM) | :Т010002 | 3046M| 1174G| | P->S |QC (RAND) 
ж $ | HASH JOIN BUFFERED | | 3046M| 1174G| 324M| PCWP | 
4 | PX RECEIVE | | 9323K| 1840М| | PCWP | 
Б. | PX SEND HASH | :TQ10000 | 9323K| 1840M| | P->P |HASH 
6 | PX BLOCK ITERATOR | | 9323K| 1840М| | PCWC | | 
7- | TABLE ACCESS FULL| A | 9323K| 1840М| | PCWP | I 
ey PX RECEIVE | | 20M| 4045M| | PCWP | I 
9 | PX SEND HASH | :TQ10001 | 20M| 4045М| | P->P |HASH 
i: 20111 PX BLOCK ITERATOR | | 20M| 4045M| | PCWC | | 
(1124 TABLE ACCESS FULL| В | 20M| 4045M| | PCWP | 


3 = access("A"."OBJECT ID"-"B"."OBJECT ID") 


两 表 如 果 进 行 的 是 并 行 HASH HASH 关联 ， 执 行 计划 Operation 会 出 现 PX SEND HASH 
关键 字 ，PQ Distrib 会 出 现 HASH 关键 字 。 

如 果 表 a 有 20G， 表 b 有 30G， 即 使 采用 并 行 HASH HASH 连接 也 很 难 跑 出 结果 ， 因 为 
要 把 两 个 表 先 映射 到 PGA 中 ， 这 需要 耗费 一 部 分 PGA， 之 后 在 进行 HASH JOIN 的 时 候 也 需 
要 部 分 PGA, 此 时 PGA 根本 就 不 够 用 , 如 果 我 们 查看 等 待 事件 , 会 发 现 进程 一 直 在 做 DIRECT 
PATH READ/WRITE TEMP。 

如 何 解 决 超级 大 表 〈 几 十 GB) 与 超级 大 表 〈 几 十 GB) 关联 的 性 能 问题 呢 ? 我 们 可 以 根 
据 并 行 HASH HASH 关联 的 思路 , 人 工 实现 并 行 HASH HASH。 下 面 就 是 人 工 实现 并 行 HASH 
HASH 的 过 程 。 

现在 我 们 创建 新 表 pl, ER a 的 结构 上 添加 一 个 字段 HASH VALUE， 同 时 根据 


8.6 ”超大 表 与 超大 表 关 联 优化 方法 


HASH VALUE 进行 LIST 分 区 。 


SQL» CREATE TABLE Р1( 





3 OWNER VARCHAR2 (30), 

4 OBJECT NAME VARCHAR2 (128), 
5  SUBOBJECT NAME VARCHAR2 (30), 
6 OBJECT ID NUMBER, 

7 DATA OBJECT ID NUMBER, 

8 OBJECT TYPE VARCHAR2 (19), 
9 CREATED DATE, 

10 LAST DDL TIME DATE, 

11 ТІМЕ5ТАМР VARCHAR2(19), 

12 STATUS VARCHAR2 (7), 

13 TEMPORARY VARCHAR2 (1), 

14 GENERATED VARCHAR2 (1), 

15 SECONDARY VARCHAR2 (1), 

16 NAMESPACE NUMBER, 

17 EDITION NAME VARCHAR2 (30) 
18" 3 

19 PARTITION BY 115%(НА5Н VALUE) 
20. % 
21 partition pO values (0), 
22 partition pl values (1), 
23 partition p2 values (2), 
24 partition p3 values (3), 
25 partition p4 values (4) 
26 ); 


Table created. 


然后 我 们 创建 新 表 p, EK b 的 结构 上 添加 一 个 字段 HASH VALUE， 同 时 根据 
HASH VALUE 进行 LIST 分 区 。 
SQL> CREATE TABLE P2( 


2 HASH VALUE NUMBER, 
3 OWNER VARCHAR2 (30), 





4 OBJECT NAME VARCHAR2 (128), 
5  SUBOBJECT NAME VARCHAR2 (30), 
6 OBJECT ID NUMBER, 

7 DATA OBJECT ID NUMBER, 

8 OBJECT TYPE VARCHAR2 (19), 
9 CREATED DATE, 

10 LAST DDL TIME DATE, 

11 TIMESTAMP VARCHAR2(19), 

12 STATUS VARCHAR2 (7), 

13 TEMPORARY VARCHAR2 (1), 

14 GENERATED VARCHAR2 (1), 

15 SECONDARY VARCHAR2(1), 

16 NAMESPACE NUMBER, 

17 EDITION NAME VARCHAR? (30) 
19. 9 

19 PARTITION BY list (HASH VALUE) 
2021 

21 partition р0 values (0), 
22 partition pl values (1), 
23 partition p2 values (2), 
24 partition p3 values (3), 
25 partition p4 values (4) 

26 ); 
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] Table created. 


请 注意 ， 两 个 表 分 区 必须 一 模 一 样 ， 如 果 分 区 不 一 样 ， 就 有 数据 无 法 关联 上 。 
我 们 将 a 表 的 数据 迁移 到 新 表 pl 中 。 


| insert into pl 






select BR 


Duy, a.* from a; --- 注 意 排除 object іа 2 null 的 数据 
commit; 


然后 我 们 将 b 表 的 数据 迁移 到 新 表 p2 中 。 


2 






select 


commit; 


insert in : 
4), b.* from b; --- 注 意 排除 object_id 2 null 的 数据 


下 面 SQL 就 是 并 行 HASH HASH 关联 的 人 工 实现 。 


select * 
from pl, p2 
where pl 


object id p2.object. id 
mm TT] 








select * 
from pl, p2 
where pl.object id = p2.object id 





select * 
from pl, p2 
where pl.object id - p2.0bject id 





select * 









wher + p2.0bject id 


.object id 
an 


此 方法 运用 了 ога hash 函数 。Oracle 中 的 HASH 分 区 就 是 利用 的 ога hash 函数 。 
ora hash 使 用 方法 如 下 。 
ora_hash ( 列 ,HASH 桶 ) HASH 桶 默认 是 4 294 967 295， 可 以 设置 0 一 4 294 967 295, 
ora hash(object id,4) t object id 的 值 进行 HASH 运算 ， 然 后 放 到 0、1、2、3、 
4 这 些 桶 里 面 ， 也 就 是 说 ora hash(object id,4) 只 会 产生 0、1、2、3、4 这 几 个 值 。 
KKE Cabo 拆 分 为 分 区 表 Cpl, p2) 之 后 ， 我 们 只 需要 依次 关联 对 应 的 分 区 ， 这 样 就 
不 会 出 现 PGA 不 足 的 问题 ， 从 而 解决 了 超级 大 表 关 联 查询 的 效率 问题 。 在 实际 生产 环境 中 ， 
需要 添加 多 少 分 区 ， 请 自己 判断 。 
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87 LIKE 语句 优化 方法 






我 们 先 创建 测试 表 T. 
| SQL» create table t as select * from dba objects; 


Table created. 


现在 有 如 下 语句 。 


| select * from t where object name like '%5Е0%'; 


因为 需要 对 字符 串 两 边 进行 模糊 匹配 ， 而 索引 根 块 和 分 支 块 存储 的 是 前 绥 数 据 (也 就 是 说 
object like 'SEQ%' 才 能 走 索 引 )， 所 以 上 面 SQL 查询 无 法 走 索 引 。 
如 果 强 制 走 索 引 ， 会 走 INDEX FULL SCAN. 


SQL» create index idx ojbname on t(object name); 





Index created. 


查看 强制 走 索引 的 执行 计划 。 


SOL» select /*+ index(t) */ * from t where object name 





208 rows selected. 


Execution Plan 


Plan hash value: 3894507753 


| Id | Operation І Name | Rows | Bytes | Cost($CPU)|Time | 
| 0 | SELECT STATEMENT | | 219 | 45333 | 2214 “(1l)|00;00;27] 
| 1 | TABLE ACCESS BY INDEX ROWID|T | 219 | 25333 | 2214 5100:00:27] 
152 | INDEX FULL SCAN |IDX OJBNAME| 3395 | | 362 (1)100:00:05| 


2 - filter ("OBJECT NAME" LIKE '$SEQ$') 


INDEX FULL SCAN 是 单 块 读 ， 性 能 不 如 全 表 扫 描 。 大 家 可 能 会 有 疑问 ， 可 不 可 以 走 
INDEX FAST FULL SCAN WE? 答案 是 不 可 以 ， 因 为 INDEX FAST FULL SCAN 不 能 回 表 ， 而 
EM SQL 查询 需要 回 表 (select *)。 

我 们 可 以 创建 一 个 表 当 索引 用 ， 用 来 代替 INDEX FAST FULL SCAN 不 能 回 表 的 情况 。 

SOL» create table index t as select object name,rowid rid from t; 


Table created. 


现在 将 SQL 查询 改写 为 如 下 SQL. 
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$83 调 优 技巧 





from t 


select * 
where rowid in (select rid from index t where object name like '&SEQ& 





改写 完 SQL 之 后 ， 需 要 让 index t 5 t ЕКЕ, [RII ib index t (Е BcE TRE UK, 
这 样 就 达到 了 让 index t 充 当 索 引 的 目的 。 
现在 我 们 来 对 比 两 个 SQL 的 autotrace 执行 计划 。 


SOL» select * from t where object name like '$SEQ$'; 
208 rows selected. 


Execution Plan 


Plan hash value: 1601196873 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time | 
| 0 | SELECT STATEMENT | | 135 | 27945 | 235 (2)| 00:00:03 | 
|% 1 | TABLE ACCESS FULL| Т | 135 | 27945 | 235 (1) | 00:00:03 


1 -~ filter("OBJECT МАМЕ" IS NOT NULL AND "OBJECT NAME" LIKE '$SEQ$') 


- dynamic sampling used for this statement (level-2) 


Statistics 


5 recursive calls 
0 db block gets 





0 physical reads 
0 redo size 
12820 bytes sent via SQL*Net to client 
563 bytes received via SQL*Net from client 
15 $SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
208 rows processed 





SQL> select 
* 


from t 
where rowid in (select 
rid 
from index t 
where object name like !%5Е0%"); 





- оу (л > Q № 


208 rows selected. 


Execution Plan 





8.8 DBLINK 优化 


Plan hash value: 2608052908 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time | 
SELECT STATEMENT 87 25839 140 (2) | 00:00:02 | 
87 25839 140 (2)| 00:00:02 | 


0 | | 
1 | NESTED LOOPS | 
24 SORT UNIQUE | 
3 TABLE ACCESS FULL | INDEX T 95 (2) | 00:00:02 | 
4 | TABLE ACCESS BY USER ROWID| T 1 (0) | 00:00:01 | 


| | | 
| | | 
| 87 | 16786 | 95 (2) | 00:00:02 | 
| | | 
| | | 


3 - filter ("OBJECT NAME" IS NOT NULL AND "OBJECT NAME" LIKE !%5Е0%") 


- dynamic sampling used for this statement (level-2) 


Statistics 


0 recursive calls 
0 db block ts 





0 physical reads 
0 redo size 
12820 bytes sent via SQL*Net to client 

563 bytes received via SQL*Net from client 
15 SQL*Net roundtrips to/from client 
1 sorts (memory) 
0 sorts (disk) 

208 rows processed 


因为 t 表 很 小 ， 表 字段 也 不 多 ， 所 以 大 家 可 能 感觉 性 能 提升 不 是 特别 大 。 当 {t 表 越 大 ， 人 性 
能 提升 就 越 明 显 。 采 用 这 个 方法 还 需要 对 index t 进行 数据 同步 , 我 们 可 以 将 index t 创建 为 物 
化 视图 ， 刷 新 方式 采用 on commit 刷新 。 


现在 有 如 下 两 个 表 ，a 表 是 远 端 表 (1800 77), b 表 是 本 地 表 〈100 行 )。 


SOL» desc a@dblink 






Name Null? Type 

ID NUMBER 

NAME VARCHAR2 (100) 
ADDRESS VARCHAR2 (100) 


SOL» select count(*) from aQdblink; 
COUNT (*) 


18550272 
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Name 


NAME 
ADDRESS 


NUMBER 
VARCHAR2 (100) 
VARCHAR2 (100) 


SQL» select count(*) from b; 


现 有 如 下 SQL. 


{ select * from aeablink，b where a.id = b.id; 


默认 情况 下 ， 会 将 远 端 表 a 的 数据 传输 到 本 地 ， 然 后 再 进行 关联 ，autotrace 的 执行 计划 


如 下 。 


SQL» set timi on 
SQL» set autot trace 
SOL» select * from aG8dblink, b where a.id = b.id; 


25600 rows selected. 





Plan hash value: 


657970699 


| 0 | SELECT STATEMENT | | 82| 19188 
|%1| BASE JOIN. | | 82| 19188 
3231 КЕМОТЕ [А | 82| 9594 
Ш Sal) TABLE ACCESS FULL|B | 100| 21700 


6  (17)| 00:00:01 
6 (17)] 00:00:01 
2 (0)| 00:00:01 
3 (0)| 00:00:01 


1 - access (Han ."Тр"="в". ftre 


Remote SQL Information 


(identified by operation id): 


2 - SELECT "ID","NAME","ADDRESS" FROM "A" "A" (accessing 'DBLINK' 


Statistics 


1477532 
19185 
1708 

0 


recursive calls 

db block gets 

consistent gets 

physical reads 

redo size. 

bytes sent via SQL*Net to client 
bytes received via SQL*Net from client 


SOL*Net roundtrips to/from client 


sorts 


(memory) 


) 





地 ， 这 时 需要 使 用 hint: driving site. FI SQL 就 是 将 b 传递 到 远 端 关联 的 示例 。 


8.8 DBLINK 优化 


0 sorts (disk) 
25600 rows processed 


远 端 表 a 很 大 ， 对 数据 进行 传输 会 耗费 大 量 时 间 ， 本 地 表 b 表 很 小 , 而且 a 和 b 关联 之 后 | 
返回 数据 量 很 少 , 我 们 可 以 将 本 地 表 b 传输 到 远 端 ， 在 远 端 进行 关联 ， 然 后 再 将 结果 集 传 回 本 








select 4 driving. aa * from aGdblink, b where a.id = b.id; 
autotrace 的 执行 计划 如 下 。 
SQL» select ЙЕ te M * from а@ар1ііпк, b where a.id = b.id; 





25600 rows selected. 





Plan hash value: 4284963264 





| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Inst | IN-OUT | 
| 0 | SELECT STATEMENT REMOTE | | 20931 | -4783К| 25565 (2)1 | 
1* 1 | HASH JOIN | | 20931 | 4783K| 25565 (2) | | 
| 2 REMOTE | B | B2 | 9594 | 2 (0) | TE 
| 3. | TABLE ACCESS FULL | А | 19М| 2173М| 25466 (1)1 ORCL | 


1 = acocess("A2","ID"z"A]","TD") 


Remote SQL Information (identified by operation id): 


2 = SELECT "ID","NAME","ADDRESS" FROM "B" "А1" (accessing '!' ) 


- fully remote statement 


Statistics 
6 recursive calls 
0 db block gets 
8 consistent gets 
0 physical reads 
0 redo size 
1428836 bytes sent via SQL*Net to client 
19185 bytes received via SQL*Net from client 
1708 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
25600 rows processed 
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将 本 地 小 表 传 输 到 远 端 关联 ， 再 返回 结果 只 需 6 秒 ， 相 比 将 大 表 传 输 到 本 地 ， 在 性 能 上 有 
巨大 提升 。 

现在 我 们 在 远 端 表 a 的 连接 列 建 立 索引 。 
| SQL> create index idx_id on a(id); 


Index created. 


因为 b 表 只 有 100 行 数 据 ，a KA 1800 万 行 数据 ， 两 表 关 联 之 后 返回 2.5 万 行 数 据 ， 我 
们 可 以 让 a 5j b серу b AM case а 作为 被 驱动 表 ， 而 且 走 连接 索引 。 


SQL» select 7% Gb) reading(b) */ * from aGdblink, b where a.id = 
528; 





25600 rows selected. 





Plan hash value: 1489534455 


| Та | Operation | Name | Rows | Bytes | Cost (%CPU)| Inst | IN-OUT | 
| 0 | SELECT STATEMENT | | 7614K| 1699M| 54680 (100) | | | 
| 1 | NESTED LOOPS | | 7614K| 1699M| 54680 (100)| | | 
| 2-| TABLE ACCESS FULL| B | 100 | 11700 | 3 (0) | | | 
| 3l REMOTE | A | 76146 | 8700К| 3 (0)| DBLINK | R-5S | 


3 ~ SELECT /*+ USE NL ("A") INDEX ("A") */ "ID","NAME","ADDRESS" FROM "A" "A" 
WHERE "ID"-:1 (accessing 'DBLINK' ) 


Statistics 
0 recursive calls 
0 db block gets 
106 consistent gets 
0 physical reads 
0 redo size 
349986 bytes sent via SQL*Net to client 
19185 bytes received via SQL*Net from client 
1708 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
25600 rows processed 


强制 a 表 走 索 引 之 后 ， 这 时 我 们 只 需 将 索引 过 滤 之 后 的 数据 传输 到 本 地 ， 而 无 需 将 a 表 所 
有 数据 传 到 本 地 ， 性 能 得 到 极 大 提升 ，SQL 耗 时 不 到 1 秒 。 
现在 我 们 将 b 表 传 输 到 远 端 ， 2. b iil йиш 


SQL» select f 
.id = b.id; 





ng(b) * from a8dblink, b where а 


25600 rows selected. 


8.8 DBLINK 优化 





Plan hash value: 557259519 


| Id | Operation IName |Комѕ | Bytes | Cost ($CPU)| Inst |IN-OUT| 
| 0 | SELECT STATEMENT REMOTE | |20931| 4783K| 20182 (1)1 | | 
| 1] NESTED LOOPS | | | | | | | 
| wi NESTED LOOPS | 120931| 4783K| 20182 (1) 1 | | 
| 33% REMOTE |B | 82| 9594 | 2 (0) | MIRS- 
I* 4 | INDEX RANGE SCAN |IDX ID| 255| | 2 (0)| ORCL| | 
| 51 TABLE ACCESS BY INDEX ROWIDIA І 255| 29835 | 246 (0)| ORCL | | 


4 -.áccess("A2",."TD"-"AT","Tptf) 


Remote SQL Information (identified by operation id): 


- fully remote statement 


Statistics 
6 recursive calls 
0 db block gets 
8 consistent gets 
0 physical reads 
0 redo size 
426684 bytes sent via SQL*Net to client 
19185 bytes received via SQL*Net from client 
1708 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
25600 rows processed 


该 查询 耗 时 2.9 秒 ， 主 要 开销 耗费 在 网 络 传输 上 ， 首 先 我 们 要 将 b 表 传 输 到 远 端 ， 然 后 将 
a 与 b 的 关联 结果 传输 到 本 地 ， 网 络 传输 耗费 了 两 次 。 我 们 可 以 设置 arraysize 减少 网 络 交互 次 
数 ， 从 而 减少 网 络 开销 ， 如 下 所 示 。 


SQL» set arraysize 1000 
SOL» select /*+ driving site(a) use nl(a,b) leading(b) */ * from a@dblink, b where a 
„а = brid; 


25600 rows selected. 





Plan hash value: 557259519 
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| Id | Operation [Name |Rows | Bytes | Cost ($CPU)|Inst  |IN-OUT| 
| 0 | SELECT STATEMENT REMOTE | 120931| 4783К| 20182 (1)1 | | 
| 1] NESTED LOOPS | | | | | | | 
"cian NESTED LOOPS | |20931| 4783K| 20182 (291 | | 
| һе 34 REMOTE |B | 82| 9594 | 2 (0) 1 t| А->8 | 
prse | INDEX RANGE 5САМ |IDX ID| 255| | 2 (0)| ORCLI| 

{теб TABLE ACCESS BY INDEX ROWID|A | 2551-298825- | 246 (0)| ORCLIL| 


4 - access ("А2". "Ір"="А1"."Ір") 


Remote SQL Information (identified by operation id): 


- fully remote statement 


Statistics 

3 recursive calls 
0 db block gets 

8 consistent gets 
0 physical reads 

0 redo size 

137698 bytes sent via SQL*Net to client 
694 bytes received via SQL*Net from client 






0 sorts (memory) 


0 sorts (disk) 
25600 rows processed 


注意 观察 执行 计划 中 统计 信息 栏目 SQL*Net roundtrips 从 1 708 减少 到 27。 当 需要 将 本 地 
表 传输 到 远 端 关 联 、 再 将 关联 结果 传输 到 本 地 的 时 候 ， 我 们 可 以 设置 arraysize 优化 SQL. 

如 果 远 端 表 a 很 大 ， 本 地 表 b 也 很 大 ， 两 表 关 联 返 回 数据 量 多 ， 这 时 既 不 能 将 远 端 表 a fe 
到 本 地 ， 也 不 能 将 本 地 表 b 传 到 远 端 ， 因 为 无 论 采 用 哪 种 方法 ，SQL 都 很 慢 。 我 们 可 以 在 本 
地 创建 一 个 带 有 dblink 的 物化 视图 ， 将 远 端 表 a 的 数据 刷新 到 本 地 ， 然 后 再 进行 关联 。 

如 果 SQL 语句 中 有 多 个 dblink 源 ， 最 好 在 本 地 针对 每 个 dblink 源 建立 带 有 dblink 的 物化 
视图 ， 因 为 多 个 dblink 源 之 间 进 行 数据 传输 ， 网 络 信息 交换 会 导致 严重 性 能 问题 。 

有 了 时候 会 使 用 dblink 对 数据 进行 迁移 , 如 果 要 迁移 的 数据 量 很 大 , 我 们 可 以 使 用 批量 游标 
进行 迁移 。 以 下 是 使 用 批量 游标 迁移 数据 的 示例 CK a@dblink 的 数据 迁移 到 b). 


declare 
cursor cur is 
select id, name, 'address from a@dblink; 
type cur_type is table of cur%rowtype index by binary_integer; 
v_cur cur_type; 
begin 
open cur; 
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8.9 对 表 进行 ROWID 切片 


loop 
fetch cur bulk collect 
into v_cur limit 100000; 
forall i in 1l .. v Cuer Count 
insert into b 
(id, name, address) 
values 
(v cur(i).id, v cur(i).name, v cur(i).address); 
commit; 
exit when cur$notfound or cur$notfound is null; 
end loop; 
close cur; 
commit; 
end; 


É 7% io uU 2 Pers > e : 
UE = > es ° - Ж - 


对 一 个 很 大 的 分 区 表 进行 UPDATE、DELETE， 想 要 加 快 执行 速度 ， 可 以 按照 分 区 ， 在 不 
同 的 会 话 中 对 每 个 分 区 单独 进行 UPDATE、DELETE。 但 是 对 一 个 很 大 的 非 分 区 表 进 行 
UPDATE、DELETE， 如 果 只 在 一 个 会 话 里 面 运 行 SQL， 很 容易 引发 UNDO 不 够 ， 如 果 会 话 
连接 中 断 ， 会 导致 大 量 数据 从 UNDO 回 深 ， 这 将 是 一 场 灾难 。 

对 于 非 分 区 表 , 我 们 可 以 对 表 按 照 ROWID 切片 , 然后 开启 多 个 窗口 同时 执行 SQL, 3x FÉ 
既 能 加 快 执行 速度 ， 还 能 减少 对 UNDO 的 占用 。 

Oracle 提供 了 一 个 内 置 函数 DBMS_ROWID.ROWID_CREATE() 用 于 生成 ROWID。 对 于 
一 个 非 分 区 表 ， 一 个 表 就 是 一 个 段 (Segment)， 段 是 由 多 个 区 组 成 ， 每 个 区 里 面 的 块 物理 上 是 
连续 的 。 因 此 ， 我 们 可 以 根据 数据 字典 ОВА ЕХТЕМТ5, DBA OBJECTS 关联 ， 然 后 再 利用 
生成 ROWID 的 内 置 函数 人 工 生 成 ROWID。 

例如 ， 我 们 对 SCOTT 账户 下 TEST 表 按 照 每 个 Extent 进行 ROWID 切片 。 


select ' and rowid between ' || '''' || 
dbms rowid.rowid create(l, 
b.data object id, 
a.relative fno, 
a.block id, 
0) || YE? 14 "апа! || КЕЛЕ BI 
dbms rowid.rowid create(l, 
b.data object id, 
a.relative fno, 
a.block id * blocks - 1, 
999) 11 0... 
from dba extents a, dba objects b 
where a.segment name = b.object name 
and a.owner - b.owner 
and b.object name - 'TEST' 
and b.owner - 'SCOTT' 
order by a.relative fno, a.block id; 


切片 后 生成 的 部 分 数据 如 下 所 示 。 


and rowid between 'AAASS5AAEAAB+SIAAA' апа 'ААА555ААЕААВ+5РАРп'; 
and rowid between 'AAASs5AAEAAB+SQAAA' and 'AAASs5AAEAAB+SXAPn'; 
and rowid between 'AAASSS5AAEAAB-*SYAAA' and 'AAASSS5AAEAAB-«SfAPn'; 
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and rowid between 'AAASS5AAEAAB4SgAAA' апа 'ААА555ААЕААВ+5пАРп'; 
and rowid between 'AAASs5AAEAAB+SoAAA' апа 'ААА555ААЕААВ+5уАРп'; 


假如 要 执行 delete test where object id»50000000, test XA 1 亿 条 数据 ， 要 
删除 其 中 5 000 万 行 数据 ， 我 们 根据 上 述 方法 对 表 按 照 ROWID 切片 。 


delete test 
where object_id > 50000000 

and rowid between 'AAASs5AAEAAB+SIAAA' and 'ААА555ААЕААВ+5РАРп'; 
delete test 
where object id » 50000000 

and rowid between 'AAASS5AAEAAB*SQAAA' and 'AAASS5AAEAAB-SXAPn'; 
delete test 
where object id » 50000000 

and rowid between 'AAASS5AAEAAB-*SYAAA' and 'AAASS5AAEAAB-*SfAPn'; 
delete test 
where object id » 50000000 

and rowid between 'AAASSS5AAEAAB*SgAAA' and 'AAASS5AAEAAB-*SnAPn'; 
delete test 
where object id » 50000000 

and rowid between 'AAASS5AAEAAB-SOAAA' and 'AAASSS5AAEAAB-4SvAPn'; 


最 后 , 我 们 将 上 述 SQL 在 不 同窗 口中 执行 , 这 样 就 能 加 快 delete 速度 , 也 能 减少 对 UNDO 
的 占用 。 | 
上 述 方法 需要 手动 编辑 大 量 SQL 脚本 ， 如 果 表 的 Extent 很 多 ， 这 将 带 来 大 工作 量 。 我 们 
可 以 编写 存储 过 程 简化 上 述 操作 。 
因为 存储 过 程 需要 访问 数据 字典 ， 我 们 需要 单独 授权 查询 数据 字典 权限 。 
grant select on dba extents to scott; 


grant select on dba objects to scott; 


CREATE OR REPLACE PROCEDURE P ROWID(RANGE NUMBER, ID NUMBER) IS 
CURSOR CUR ROWID IS 
SELECT DBMS ROWID.ROWID CREATE (1, 
B.DATA OBJECT ID, 
A.RELATIVE FNO, 
A.BLOCK ID, 
0) ROWIDI, 
DBMS ROWID.ROWID CREATE(1, 
B.DATA OBJECT ID, 
A.RELATIVE FNO, 
A.BLOCK ID + BLOCKS - 1, 
999) ROWID2 
FROM DBA EXTENTS A, DBA OBJECTS B 
WHERE A.SEGMENT NAME = B.OBJECT NAME 
AND A.OWNER = B.OWNER 
AND B.OBJECT NAME = 
AND B.OWNER = scort 
AND MOD(A.EXTENT ID, RANGE) 
V SQL VARCHAR2 (4000); 
BEGIN 
FOR CUR IN CUR ROWID LOOP 
V SQL := Mü 16 
EXECUTE IMMEDIATE V SQL 
USING CUR.ROWID1, CUR.ROWID2; 
COMMIT; 
END LOOP; 





lI 


ID; 





0 and rowid between :1 and :2'; 


810 SQL 三 段 分 拆 法 


END; 
/ 


如 果 要 将 表 切 分 为 6 份 ， 我 们 可 以 在 6 个 窗口 中 依次 执行 。 


begin 

p_rowid(6, 0); 
end; 
/ 
begin 

p_rowid(6, 1); 
end; 
/ 
begin 

p rowid(6, 2); 
end; 
/ 
begin 

p rowid(6, 3); 
end; 
/ 
begin 

p_rowid(6, 4); 
end; 
/ 
begin 

p rowid(6, 5); 
end; 
/ 


这 样 就 达到 了 将 表 按 ROWID 切片 的 目的 。 在 工作 中 , 大 家 可 以 根据 自己 的 具体 需求 对 存 
储 过 程 稍 作 修改 〈 阴 影 部 分 )。 


如 果 要 优化 的 SQL 很 长 ， 我 们 可 以 将 SQL 拆 分 为 三 段 ， 这 样 就 能 快速 判断 SQL 在 写法 
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select 与 from 之 问 最 好 不 要 有 标量 子 查询 ， 也 不 要 有 — 因为 有 标量 子 查询 或 者 
是 自 定义 函数 ， 会 导致 子 查询 或 者 函数 中 的 表 被 反复 扫描 。 

from 与 where 之 间 要 关注 大 表 ， 因 为 大 表 很 容易 引起 性 能 问题 ， 同 时 要 留意 子 查询 和 视 
图 ， 如 果 有 子 查 询 或 者 视图 ， 要 单独 运行 ， 看 运行 得 快 或 是 慢 ， 如 果 运 行 慢 需要 单独 优化 ; A 
外 要 注意 子 查 询 / 视 图 是 否 可 以 谓词 推 入 ， 是 否 会 视图 合并 ， 最 后 还 要 留意 表 与 表 之 间 是 内 连 
接 还 是 外 连接 ， 因 为 外 连接 会 导致 符 套 循环 无 法 改 驱 动 表 。 

where 后 面 需要 特别 注意 子 查 询 ， 要 能 判断 各 种 子 查询 写法 是 否 可 以 展开 (unnest)， 同 时 
也 要 注意 where 过 滤 条 件 ， 尽 量 不 要 在 where 过 滤 列 上 使 用 函数 ， 这 样 会 导致 列 不 走 索 引 。 

在 工作 中 , 我 们 要 养 成 利用 SQL 三 段 分 拆 方法 的 习惯 , 这 样 能 大 大 提升 SQL 优化 的 速度 。 
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本 章 将 会 带 大 家 领略 多 种 多 样 的 SQL 优化 方法 ， 为 大 家 以 后 优化 SQL 提供 宝贵 的 参考 
见 





2015 年 ， 一 位 佛山 的 朋友 说 某 沙 发 厂 ERP 系统 出 现 大 量 read by other session 等 待 ， 前 台 
用 户 卡 了 一 天 。 数 据 库 版 本 是 Oracle11gR2， 请 求 协助 优化 。 我 们 远程 连接 到 朋友 电脑 之 后 ， 
ыа ск е md 9-1 d 





从 上 面 查询 中 我 们 可 以 看 到 ， 同 时 运行 SQL: Isvyhsn0g56gd. 4 5| read by other session 
等 待 ， 于 是 从 共享 池 中 抓 出 该 SQL 的 执行 计划 ， 如 图 9-2 所 示 。 















































9.1 组 合 索引 优化 案例 


SQL 文本 如 下 。 
SELECT * 
FROM PRODDTA.F4111 
WHERE ((ILDCT = :1 AND ILFRTO = :2 AND ILMCU = :3 AND ILDOC = :4)) 


ORDER BY ILUKID ASC 


从 执行 计划 中 Id=3 我 们 可 以 看 到 , 该 SQL 走 的 是 ILMCU 这 个 列 的 索引 。 如 图 9-3 所 示 ， 
表 中 一 共有 2 510 970 行 数据 。 


select count(*) from PRODDTA.F4111] 





图 9-3 
ILMCU 列 的 数据 分 布 如 下 ， 如 图 9-4 所 示 。 


select /*+ full(a) */ count(*),ilmcu from PRODDTA.F4111 a group by ilmcu orden hy 1 desc; 





图 9-4 


ILMCU 列 的 数据 分 布 极 不 均衡 。 当 询问 当天 做 的 是 不 是 SF10 的 业务 时 ， 朋 友 确 认 是 做 
的 SF10 的 业务 。 这 就 不 难 解 释 为 什么 前 台 用 户 抱怨 卡 了 一 天 。 从 2510970 条 数据 中 查询 
1 424 246 条 数据 还 走 索 引 ， 这 明显 大 错 特 错 。 这 个 错误 的 执行 计划 会 导致 产生 大 量 的 单 块 读 ， 
因为 SQL 执行 绥 慢 , 某 些 耐 不 住 性 子 的 用 户 可 能 会 多 次 点 击 或 刷新 前 台 , 并 且 因为 做 的 是 SF10 
的 业务 ， 前 台 操 作 人 员 可 能 多 达 几 十 位 。 正 是 因为 有 很 多 人 在 同时 运行 该 SQL， 而 且 该 SQL 
跑 得 很 慢 ， 又 是 单 块 读 ， 所 以 就 发 生 了 多 个 进程 需要 同时 读 取 同 一 个 块 的 情况 ， 这 就 是 产生 
read by other session 的 原因 。 

该 SQL 一 共有 4 个 过 滤 条 件 , 下 面 我 们 分 别 查看 剩余 3 个 过 滤 条 件 的 数据 分 布 , 如 图 9-5. 
图 9-6、 图 9-7 所 示 。 





select /*+ full(a) */ count(*),ilfrto from PRODDTA.F4111 a group by ilfrto onder by 1 desc; 





Holger 


B 9-5 
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图 9-6 


select /*+ full(a) */ count(*),ILDCT from PRODDTA.F4111 a group by ПОСТ order by 1 desc; 





89-7 


根据 以 上 查询 结果 ， 我 们 发 现 ，ILDOC 列 的 数据 分 布 最 为 均匀 ，ILDCT 列 的 数据 分 布 次 
之 ，ILMCU 列 的 数据 分 布 倒 数 第 二 ，ILFRTO 列 的 数据 分 布 最 不 均衡 。 因 为 SQL 都 是 根据 这 
些 列 进行 等 值 过 滤 ， 于 是 建立 如 下 组 合 索 引 。 


| create index idx Е4111 docdctilmcufrto on FA111(ILDOC,ILDCT,ILMCU,ILFRTO) online nolo 
gging; 


创建 完 索 引 之 后 ， 系 统 中 的 read other session 等 待 陆续 消失 ， 系 统 立 刻 恢复 正常 ， 前 台 用 
户 原 本 执行 了 一 天 还 没完 成 的 业务 现在 可 以 瞬间 完成 。 

为 什么 在 查询 ILMCU 列 的 数据 分 布 的 时 候 会 使 用 HINT:FULL WE? 这 是 因为 原本 的 SQL 
走 该 列 的 索引 已 经 执行 不 出 结果 ， 如 果 不 加 HINT, 万 一 SQL 查询 又 使 用 了 该 索引 ， 这 不 是 火 
НЫ? 至 于 后 面 的 HINT， 其 一 是 因为 复制 粘贴 ， 其 二 是 因为 表 已 经 全 表 扫 描 过 了 ， 后 面 
的 全 表 扫 描 可 以 直接 从 buffer cache 获取 数据 。 

虽然 通过 创建 组 合 索引 优化 了 该 SQL， 但 是 ， 在 创建 组 合 索 引 之 前 ， 如 果 优 化 器 能 够 准 
确 地 知道 ILMCU 列 的 数据 分 布 ， 那 么 执行 计划 也 不 会 走 该 列 的 索引 而 会 走 其 他 列 的 索引 【如 
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果 存 在 索引 ), 或 者 走 全 表 扫 描 。 即 使 该 SQL 走 全 表 扫 描 ， 那 也 比 走 索引 扫描 好 太 多 ， 至 少 不 
会 被 卡 死 ， 不 会 引发 前 台 用 户 被 卡 一 天 ， 最 多 被 卡 一 小 会 儿 。 为 什么 优化 器 选择 了 走 该 列 的 索 
引 呢 ?请 注意 观察 执行 计划 中 的 Id=3，Rows=1， 优 化 器 认为 走 ILMCU 列 的 索引 只 返回 一 行 
数据 。 很 明显 该 表 统 计 信息 有 问题 ， 而 且 该 列 很 可 能 没有 收集 直方 图 。 大 家 特别 是 ОВА, 一 
定 要 重视 表 的 统计 信息 ， 另 外 也 要 牢 牢 掌握 索引 知识 ， 理 解 透 了 ， 就 能 解决 80% 左 右 的 关于 
OLTP 的 SQL 性 能 问题 。 如 果 数 据 库 系统 不 是 OLTP 系统 ， 而 是 ERP 系统 ， 或 者 是 OLAP 中 
的 报表 系统 、ETL 系统 等 ， 只 吃透 索引 没 太 大 帮助 ， 必 须 精通 阅读 执行 计划 、SQL、 各 种 SQL 
等 价 改写 ， 熟 悉 分 区 ， 同 时 熟悉 系统 业务 ， 这 样 才能 游 思 有 余地 进行 SQL 优化 。 


本 案例 发 生 在 2010 年 ， 当 时 作者 罗 老 师 在 惠普 担任 开发 DBA,， 支 撑 宝 洁 公司 的 数据 仓库 
项 目 。 为 了 避免 泄露 信息 ， 他 对 SQL 语句 做 了 适当 修改 。ETL 开发 人 员 发 来 邮件 说 有 个 long 
running job， 执 行 了 两 小 时 左右 还 未 完成 ， 需 要 检查 一 下 。 收 到 邮件 后 ， 立 即 检查 数据 库 中正 
在 运行 的 SQL， 经 过 与 ETL 开发 人 员 确 认 ， 抓 出 执行 计划 (为 了 排版 需要 ， 删 除了 执行 计划 
中 非 关键 部 分 )。 


SQL» select * from table (dbms_xplan.display_cursor('ghlhwl8uz6dcm',0)); 






PLAN TABLE OUTPUT 


create table ОРТ REF BASE UOM TEMP SDIM parallel 2 

nologging as SELECT PROD SKID, RELTV CURR ОТҮ, 

STAT CURR VAL, BAR CURR CODE FROM OPT REF BASE UOM DIM VW 
Plan hash value: 2933813170 





| Id | Operation | Name | Rows | Bytes | 
| 0 | CREATE TABLE STATEMENT | | | | 
| 1 | PX COORDINATOR | | | | 
| 2 | PX SEND ОС (RANDOM) | :TO10001 54-| 2916 | 
| 3 | LOAD AS SELECT | | | | 
| 4 | HASH GROUP BY | | 54 | 2916 

| Б PX RECEIVE | 54 |]-— 2916 | 
| 6 | PX SEND HASH | :TQ10000 54 | 2916 | 
| 7 1 HASH GROUP BY | | 54 | 2916 | 
| 8" NESTED LOOPS | | | 
| s| NESTED LOOPS | | 3134 | 165K| 
11 4X0) PX BLOCK ITERATOR | | | 
|*- 13 | TABLE ACCESS FULL | OPT REF UOM TEMP SDIM 3065 | 104K| 
|* 121 INDEX RANGE SCAN | PROD DIM PK 57 | 

|* 13) TABLE ACCESS BY INDEX ROWID| PROD DIM | ab | 39. | 
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11 - access(:Z>=:Z AND :2<-:2) 
filter("UOM"."RELTV CURR QTY"-1) 
12 - access("PROD"."PROD SKID"-"UOM"."PROD SKID") 
13 - filter(("PROD"."BUOM CURR SKID" IS NOT NULL AND 
"PROD"."PROD END DATE"-TO DATE(' 9999-12-31 00:00:00', 'syyyy-mm-dd 
hh24:mi:ss') AND "PROD"."CURR IND"-'Y' AND "PROD"."BUOM СОВЕ SKID'"-"UOM"."UOM SKID")) 


这 个 工作 很 简单 ， 就 是 create table .....as select .....« 


create table OPT REF BASE UOM TEMP SDIM parallel 2 nologging 
as SELECT PROD SKID, RELTV CURR ОТҮ, STAT СОКЕ VAL, BAR CURR CODE 
FROM OPT REF BASE UOM DIM VW; 


ОРТ REF BASE ПОМ DIM VW 是 一 个 视图 ， 该 视图 定义 : 


SELECT UOM.PROD SKID, 
MAX (UOM.RELTV CURR ОТҮ) RELTV CURR ОТҮ, 
MAX (UOM.STAT CURR VAL) STAT CURR VAL, 
MAX (UOM.BAR CURR CODE) BAR CURR CODE 
FROM OPT REF UOM TEMP SDIM UOM, 
REF PROD DIM PROD 
WHERE UOM.RELTV CURR QTY - 1 
AND PROD.CURR IND = 'Y' 
AND PROD.PROD END DATE - TO DATE ('31-12-9999', 'dd-mm-yyyy') 
AND PROD.PROD SKID = UOM.PROD SKID 
AND PROD.BUOM CURR SKID = UOM.UOM SKID 
GROUP BY UOM.PROD SKID; 


这 个 视图 的 查询 效率 就 直接 决定 了 ETL JOB 的 效率 , 现在 我 们 查看 这 个 视图 的 执行 计划 。 


SQL> explain plan for SELECT UOM.PROD SKID, 


2 MAX (UOM.RELTV CURR ОТҮ) RELTV CURR QTY, 

3 MAX (UOM.STAT CURR VAL) STAT CURR VAL, 

4 MAX (UOM.BAR CURR CODE) BAR CURR CODE 

5 FROM ОРТ REF UOM TEMP SDIM UOM, 

6 REF PROD DIM PROD 

7 WHERE UOM.RELTV CURR QTY - 1 

8 AND PROD.CURR IND = 'Y' 

9 AND PROD.PROD END DATE = TO DATE ('31-12-9999', 'dd-mm-yyyy') 
10 AND PROD.PROD SKID = UOM.PROD SKID 
11 AND PROD.BUOM CURR SKID = UOM.UOM SKID 


12 GROUP BY UOM.PROD SKID; 
Explained. 
SQL» select * from table(dbms xplan.display); 


PLAN TABLE OUTPUT 


Plan hash value: 3215660883 


| Id |Operation | Name |Rows | Bytes | Cost($CPU)| 
| 0 |SELECT STATEMENT | | FO 4212 | 15507 (1)! 
| 1 | HASH GROUP BY | | 78) 4212 | 15507  (1)| 
| 2 | NESTED LOOPS | | | | | 
ІІ» 78 NESTED LOOPS | | 3034| 159K| 15506  (1)| 
14 | TABLE ACCESS FULL |OPT REF UOM TEMP SDIM| 2967 | 101K| 650 (14)| 
[e 93.3 INDEX RANGE SCAN | PROD DIM PK | 3| | ea 407) 
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1556: 4 TABLE ACCESS BY INDEX ROWID|PROD DIM 1| 19. | 82 (094 





4 - filter ("UOM"."RELTV_CURR_QTY"=1) 

5 = access ("PROD"."PROD . SKID"- "UOM"."PROD SKID") 

6 - filter("PROD"."BUOM | "CURR SKID" IS NOT NULL AND "PROD"."PROD END DATE"-TO DATE(' 
9999-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "PROD"."CURR IND"-' 


Y' AND 
"PROD"."BUOM CURR SKID"-"UOM"."UOM SKID") 


22 rows selected. 


Id=4 ЭММТИШМАН, А05). СВО 估算 14-4 返回 2 967 行 数 据 。 对 
ГЕКЕ, 我 们 首先 要 检查 驱动 表 返 回 的 真实 行 数 是 否 与 估算 的 行 数 有 较 大 偏差 , 现在 查看 
驱动 表 总 行 数 。 

SQL> select count(*) from OPT REF UOM TEMP SDIM; 


COUNT (*) 


2137706 


我 们 碍 看 驱动 表 返 回 的 真实 行 数 。 
SQL» select count(*) from ОРТ REF UOM TEMP SDIM where "RELTV CURR QTY"-1; 


COUNT (*) 


946432 


驱动 表 实 际 上 返回 了 94 万 行 数据 ， 与 估算 的 2967 WAER. WEAF, KIRKEE 
多 少 行 数据 ， 被 驱动 表 就 会 被 扫描 多 少 次 ， 这 里 被 驱动 表 会 被 扫描 94 万 次 ， 这 就 解释 了 为 什 
А SQL 执行 了 两 个 小 时 还 没 执 成 功 。 显 然 执 行 计划 是 错误 的 ， 应 该 走 HASH 连接 。 

本 案例 是 因为 Rows 估算 有 严重 偏差 ， 导 致 走 错 执行 计划 。Rows 估算 与 统计 信息 有 关 。 
Id=4 过 滤 条 件 是 RELTV CURR ОТҮ = 1， 现 在 我 们 来 查看 表 和 列 的 统计 信息 。 


SQL» select a.table name name ,a.column name,b.num rows,a.num distinct Cardinality, 
2 a.num distinct/b.num rows selectivity,a.histogram from dba tab col statistics a, 
3 dba tables b where a.owner-b.owner and a.table name-b.table name 
4 and a.table name-'OPT REF UOM TEMP SDIM' and a.column name-'RELTV CURR QTY'; 


NAME COLUMN NAME NUM ROWS CARDINALITY SELECTIVITY  HISTOGRAM 


ОРТ REF UOM TEMP SDIM RELTV CURR QTY 2160000 728 .000337037 МОМЕ 


统计 信息 中 表 总 行 数 有 2 160 000 行 数据 ， 与 真实 的 行 数 (2 137 706) 十 分 接近 ， 这 说 明 
表 的 统计 信息 没有 问题 。 RELTV_CURR QTY 列 的 基数 等 于 728， 没 有 直方 图 (HISTOGRAM 
=NONE)。 为 什么 Id=4 会 估算 返回 2967 (Т ЖЕЛЕ? 正 是 因为 RELTV_CURR_QTY 列 基数 太 
低 ， 而 且 没 有 收集 直方 图 ，CBO 认为 该 列 数据 分 布 是 均衡 的 ， 导 致 在 估算 Rows 的 时 候 ， 直 
接 以 表 总 行 数 / 列 基数 =216 000/728=2967 来 进行 估算 。 所 以 我 们 需要 对 RELTV_CURR QTY 
列 收集 直方 图 。 
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SQL> BEGIN 
2 DBMS STATS.GATHER TABLE STATS(ownname => 'XXXX', 
3 tabname => "ОРТ REF UOM TEMP SDIM', 






4 estimate percent => 100, 

Без ot for columns RELTV CURR ОТҮ size skewonly', 
6 degree => DBMS STATS.AUTO DEGREE, 

7  cascade-»TRUE 

8 ; 

9 END; 

107 7 


PL/SQL procedure successfully completed. 


收集 完 直 方 图 之 后 ， 我 们 再 来 查看 执行 计划 。 


SQL» explain plan for SELECT UOM.PROD SKID, 


2 MAX (UOM.RELTV CURR QTY) RELTV CURR QTY, 

3 MAX (UOM.STAT CURR VAL) STAT CURR VAL, 

4 MAX (UOM.BAR CURR CODE) BAR CURR CODE 

5 FROM ОРТ REF UOM TEMP SDIM UOM, 

6 REF PROD DIM PROD 

7 WHERE UOM.RELTV CURR QTY - 1 

8 AND PROD.CURR IND = 'Y' 

9 AND PROD.PROD END DATE = TO DATE ('31-12-9999', 'dd-mm-yyyy') 
10 AND PROD.PROD SKID = UOM.PROD SKID 
11 AND PROD.BUOM CURR SKID - UOM.UOM SKID 


12 GROUP BY UOM.PROD SKID; 
Explained. 
SQL» select * from table(dbms xplan.display); 
PLAN TABLE OUTPUT 


Plan hash value: 612020119 


| Id [Operation | Name [Rows | Bytes |TempSpc| Cost($CPU)| 
| 0 [SELECT STATEMENT | |12097| 637K| | 44911 (5) | 
| 1 | HASH GROUP BY | |12097| 637К| | 44911 (5)| 
|%2| HASH JOIN | | 951K| 48M| 29M| 44799  (5)| 
|* 31] TABLE ACCESS FULL| PROD DIM | 998К| 18M| | 43022 (5)| 
[54-3 TABLE ACCESS FULL| OPT REF UOM TEMP SDIM | 951K| 31M| | 654 (15) | 


Predicate Information (identified by operation id): 


2 - access("PROD"."PROD SKID"-"UOM"."PROD SKID" AND 
"PROD"."BUOM СОВА SKID"-"UOM"."UOM SKID") 

3 - filter("PROD"."BUOM CURR SKID" IS NOT NULL AND "PROD"."PROD END DATE"-TO DATE(' 
9999-12-31 00:00:00', 'syyyy-mm-dd hh24:mi:ss') AND "PROD"."CURR IND"-'Y') 

4 - filter("UOM"."RELTV СОВА QTY"-1) ` 


20 rows selected. 


现在 执行 计划 自动 走 了 HASH 连接 ， 这 才 是 正确 的 执行 计划 ， 走 了 正确 的 执行 计划 之 后 ， 
SQL 能 在 8 分 钟 左右 执行 完毕 。 
我 们 也 可 以 换 种 思路 优化 该 SQL。 该 SQL 属于 ETL，ETL 一 般 都 需要 清洗 大 量 数据 ， 两 
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9.3 NL 被 驱动 表 不 能 走 INDEX SKIP SCAN 


表 关 联 处 理 大 量 数据 应 该 走 HASH 连接 ， 所 以 我 们 可 以 直接 让 两 个 表 走 HASH 连接 。 男 外 该 
SQL 有 分 组 汇总 (GROUP BY), 需要 分 组 汇总 的 SQL 一 般 也 是 处 理 大 量 数 据 , 基于 此 该 SQL 
也 应 该 走 HASH 连接 。 


有 如 下 执行 计划 (从 АМЕ 中 抓 出 )。 


SQL» select * from table(dbms xplan.display awr('3m7f7xdpkdrtv', NULL, NULL, 'ALL')) ; 

SQL ID 3m7f7xdpkdrtv 

select a.int id,a.zh label,a0.zh label from VIEW RMS POS PORT a inner 

join (select int 39,235 label from RMS LOCALNET _ POS IS 

stateflag-:"SYS B 00") a0 on EOUGhar(avup pos id) (аб, 

where a0.zh_ label in (:"SYS B 01",:"SYS B 02", === B_ 03", :USYS | В | 04", 
:"SYS B 05",:"SYS B 06",:"SYS B 07",:"SYS B 08",:"SYS B 09",:"SYS B 10") 
and :"SYS B 11"-:"SYS B 12" and (a.zh label in  (:"SYS B 13")) and 

a.stateflag-:"SYS B 14" 





j£ id) 









Plan hash value: 494215470 


| Id | Operation | Name | Rows | Bytes | 
| 0 | SELECT STATEMENT | | | | 
| 1 | FILTER | | | | 
| 20) NESTED LOOPS | | kd 94 | 
| 3-) INDEX RANGE SCAN | RMS JK POS PORT PK | 1 | 43 

| 4 | TABLE ACCESS BY INDEX ROWID| RMS С LOCALNET _ POS | de Sa | 
| 5; || INDEX 5КІР 5САМ | RMS LOCALNET | POS PUI | 357) | 


SEL$D26F4AE5 

SEL$D26F4AE5 / RMS_JK_POS_PORT@SEL$2 
SEL$D26F4AE5 / RMS_LOCALNET_POS@SEL$3 
SEL$D26F4AE5 / RMS LOCALNET POS@SELS$3 


iX SQL 在 AWR 中 属于 TOP SQL， 执 行 计 划 走 了 娠 套 循环 ， 被 驱动 表 走 了 INDEX SKIP 
SCAN. 在 第 5 章 中 我 们 讲 到 ， 媒 套 循 环 被 驱动 表 只 能 走 INDEX UNIQUE SCAN 或 者 INDEX 
RANGE SCAN。 为 什么 嵌 套 循环 被 驱动 表 不 能 走 INDEX SKIP SCAN 呢 ? ОЕА АКЕ ЕҚ 
会 传 值 ， 从 驱动 表 传 值 给 被 驱动 表 ， 传 值 相当 于 过 滤 条 件 。 有 过 滤 条 件 但 是 走 了 INDEX SKIP 
SCAN， 很 有 可 能 是 被 驱动 表 连 接 列 没 包含 在 索引 中 ， 或 者 连接 列 在 索引 中 放 错 了 位 置 。 

被 驱动 表 连 接 列 是 int id， 现在 我 们 查看 索引 RMS LOCALNET POS РІЛ 具体 情况 。 


SQL» SELECT DBMS METADATA.GET DDL('INDEX','RMS LOCALNET POS PUI','HBRMW6') FROM DUAL; 


льш н 
! 


CREATE INDEX "HBRMW6"."RMS LOCALNET POS PUI" ON "HBRMW6"."RMS LOCALNET POS" (8РЕО Т 
ASK ID", "STATEFLAG") 

PCTFREE 10 INITRANS 2 MAXTRANS 255 COMPUTE STATISTICS 

STORAGE(INITIAL 65536 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645 

PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1 
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BUFFER POOL DEFAULT FLASH CACHE DEFAULT CELL FLASH CACHE DEFAULT) 
TABLESPACE "HBRMW TBS" 


被 驱动 表 索 引 中 竟然 没有 包含 连接 列 。 这 说 明 该 执行 计划 是 错误 的 。 我 们 将 连接 列 和 过 滤 
列 组 合 起 来 创建 组 合 索引 ， 从 而 解决 该 SQL 性 能 问题 。 





一 位 上 海 的 朋友 说 以 下 SQL 执行 不 出 结果 。 


with tab as ( 





select bb.cashier shop no, bb.merch loc name,aa.txn date, 
case when aa.merch id-bb.merch id апа aa.card no-bb.card no then ' 本 店 会 员 else ' 他 店 
会 员 ' end shop no, 

count (distinct aa.card | по) card num, 

sum( case when aa.p | code in ('*7646','7686','7208') then -1 else 1 end ) count num, 

sum(case when аа.р code in ('7646','7686','7208') then 0- 

case when aa.txn amt»aa.earning amt then aa.txn amt else aa.earning amt end 
else case when aa.txn amt»aa.earning amt then aa.txn amt else aa.earning amt e 

nd enaj txn amt 





where aa.txn | date between bb.txn date Ad bb. rem: txn dein and 

aa.p code in ('7641','1687', 7207", '7646','7686','7208") 

and aa.status in ('1','R') 

group by bb.cashier shop no, bb.merch loc name,aa.txn date,aa.merch id, 

case when aa.merch id-bb.merch id and aa. card | no-bb. card | no then ' 本店 会 员 else ' 他 店 
会 员 ' end 

order by aa.merch id, aa.txn date; 


执行 计划 如 下 。 
Plan hash value: 4271695044 


| Id |Operation | Name | Rows | Bytes | Cost ($CPU) | 
| 0 |SELECT STATEMENT | | 15165096737. (Ey 
| 1 [ SORT GROUP BY | | i5]2650[96737 ` {1)] 
| 2| VIEW |VW БАС 0 | -"18|2650]96735: (1)] 
] 1 HASH GROUP BY | І. 151 2430[96735 (y| 
| 3v] NESTED LOOPS | [. 51 430196734 (1) | 
[ 5) NESTED LOOPS | |2213|2430|96734  (1)| 
[ч бе] NESTED LOOPS | | 1| 103] 542 (1) 
Im 1] NESTED LOOPS | | i| 65) 58 (0)| 
ШЕК] TABLE ACCESS BY INDEX ROWID ITB BILL TEST | 361 864| 20 (0)1 
[> Ө | INDEX RANGE SCAN |TMP INDEX BILL 01 | 37| | 310) | 
|*z0o 1 TABLE ACCESS BY INDEX ROWID |ТВ MERCH | TJ 41) 3! (0)] 
ЗЕ | INDEX RANGE SCAN |Il MERCH | 11 | 1- 40)] 


9.5 INDEX FAST FULL SCAN 优化 案例 


ү! | TABLE ACCESS BY INDEX ROWID ITB CARD | 21- 76| 484 (1) 
|421 | INDEX RANGE SCAN |І1 CARD OPEN OWNER | 3855 | | 24  (0)| 
|%14 | INDEX RANGE SCAN |I2 TRANS 910222131 |85972 (1) | 
ILS. | TABLE ACCESS BY GLOBAL INDEX ROWID|TB TRANS |. 5613304196193 (7)| 


Predicate Information (identified Бу operation id): 


9 — access("T","NBR GROUP"E'T61') 
filter("T"."CARD NO" IS NOT NULL) 

10 = filter("A","MERCH ID" NOT LIKE '0$') 

11 - access("T"."CARD NO"-"A","CASHIER SHOP NO") 

12 - filter("AA"."MBR REG DATE"»e"T'", "CUST ID" AND "AA". "MBR REG DATE"«-TO CHAR (LAS 
T DAY(ADD MONTHS 

(ТО DATE("T"."CUST ID",'yyyymmdd'),1)),'yyyymmdd"')) 

13 ~ access("AA"."CARD OPEN OWNER"-"A"."MERCH ID") 

filter("AA"."CARD OPEN OWNER" IS NOT NULL) 

14 - access("AA". "ТХМ DATE"»-"T","CUST ID" AND "АА", "МЕКСН ID"-"AA",."CARD OPEN OWNE 
R" AND "AA"."TXN DATE"«-TO CHAR(LAST DAY (ADD MONTHS(TO DATE("T"."CUST ID",'yyyymm 
dd'),1)),'yyyymmdad')) 

filter("AA"."MERCH ID"2"AA","CARD OPEN OWNER") 

15 - filter(("AA". "P CODE"-'7207' OR "AAM TP- CODE"-'7208' OR "AA". TP СОВЕ"! 7646' O 
R "АА". "Р СОрЕ"='7647' 

OR "AA"."P CODBE"-S'7686' OR "AA"."P CODE"=" 7687") AND ("AA"."STATUS"-'I" OR "AX 
" "STATUS"-'mg' ) ) 


我 们 拿 到 一 条 需要 优化 的 SQL 语句 ， 怎 么 入 手 呢 ? 首先 要 看 SQL 写法 。 可 以 利用 SQL 
三 段 分 拆 方法 ， 先 观察 SQL 语句 。 该 SQL 语句 有 个 with as 子 句 取 名 为 ttb， 主 查询 中 就 是 
tb trans 与 tab 进行 关联 。with as 子 句 一共 返回 6 000 多 行 数 据 ， 可 以 1 秒 内 出 结果 ，tb_trans 
有 两 亿 条 数据 。 执 行 计划 中 ，with as 子 查询 作为 一 个 整体 并 且 作为 藤 套 循环 驱动 表 ，tb_trans 
作为 髓 套 循环 被 驱动 表 ， 乍 一 看 ， 这 也 符合 驱 套 循环 关联 原则 ， 小 表 驱 动 大 表 ， 大 表 走 索引 。 
但 是 该 SQL 执行 不 出 结果 , 最 大 的 可 能 就 是 tab 与 tb trans 关联 之 后 返回 数据 量 太 多 ， 因 为 返 
回 结果 集 太 多 ， 被 驱动 表 走 索引 ， 也 就 是 说 该 SQL 可 能 是 被 驱动 表 走 索引 返回 数据 量 太 多 导 
致 性 能 问题 。 于 是 检查 被 驱动 表 连 接 列 merch id 基数， 基数 很 低 ，tab:tb trans 是 1 比 几 十 万 
关系 。 


因为 被 驱动 表 tb_trans ^ tab 是 几 十 万 比 1 的 关系 ,这 时 就 不 能 走 撕 套 循 环 了 ,只 能 走 HASH 
连接 ， 于 是 使 用 HINT: use_hash(aa,bb) 优 化 SQL， 最 终 该 SQL 可 以 在 1 小 时 左右 执行 完毕 。 
如 果 开 启 并 行 查询 可 以 更 快 。 






2016 年 ,北京 一 位 游戏 公司 的 朋友 说 以 下 SQL 最 慢 的 时 候 要 执行 40 分 钟 , 最 快 的 时 候 只 
需要 几 秒 至 十 来 秒 就 可 以 执行 完毕 。 


idle> SELECT COUNT (DISTINCT IDFA) 
FROM SYS ACTIVATION SDK IOS Т1 

WHERE CREATE TIME >= TRUNC (sysdate) 
AND CREATE TIME < TRUNC(sysdate) + 1 
AND GAME ID - 153 
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AND NOT EXISTS (SELECT MAP Mash aj %/ IDFA 
FROM SYS ACTIVATION SDK IOS T2 
WHERE CREATE TIME < TRUNC (sysdate)-1 
AND T2.GAME ID - 153 
AND T1.IDFA = T2.IDFA) ; 


执行 计划 如 下 。 


Execution Plan 


Plan hash value: 3686453232 


| Id | Operation | Name | Rows| Bytes | 
| 0 | SELECT STATEMENT | | Taj 76 

| 1 | SORT GROUP BY | | 1-5 76 

(% | FILTER | | | | 
е = {| HASH JOIN ANTI | | ӨЗ | 17068 | 
itor INDEX RANGE SCAN| SYS ACTIVATION SDK IOS Ірх1 | 304 | 11552 | 
iiw 5n INDEX RANGE SCAN| SYS ACTIVATION SDK IOS IDX1 | 888K| 32M | 


2 - filter (TRUNC (SYSDATEG ! ) «TRUNC (SYSDATEQ ! ) +1) 

3 = access ("T1","IDFA"-"T2","TDFA") 

4 - access("GAME ID"-153 AND "CREATE TIME"2-TRUNC(SYSDATEG!) AND 
"CREATE TIME"«TRUNC (SYSDATEQ ! ) +1) 

a access("T2"."GAME ID"-153 AND "CREATE TIME"«TRUNC (SYSDATEQ ! ) -1) 
filter("T2"."IDFA" IS NOT NULL) 


该 SQL 是 一 个 自 关 联 ,SQL 语句 里 面 有 HASH: НАЅН AJ #7: SQL ЖН HASH ANTI JOIN 
进行 关联 。 该 SQL 的 确 走 的 是 HASH ANTI JOIN， 而 且 都 是 通过 同一 个 索引 访问 数据 ， 没 有 
回 表 。 表 SYS ACTIVATION SDK IOS Я 146, Ж5| SYS ACTIVATION SDK 105 IDXI 有 
2.5G， 根 据 (game id,create time,idfa) 创建 。 

两 表 关 联 ， 我 们 要 搞 清 楚 表 大 小 以 及 表 过 滤 之 后 返回 的 行 数 。 这 里 表 大 小 已 经 清楚 。 

查看 T1 返回 行 数 。 


SELECT COUNT (DISTINCT IDFA) 
FROM SYS_ACTIVATION_SDK_IOS T1 

WHERE CREATE TIME >= TRUNC(sysdate) 
AND CREATE TIME < TRUNC(sysdate) + 1 
AND GAME ID - 153; 


ТІ 返回 11 799 行 数据 。 我 们 查看 T2 返回 行 数 。 


select count(*) 
from (SELECT IDFA 
FROM SYS ACTIVATION SDK IOS T2 
WHERE CREATE TIME « TRUNC(sysdate) - 1 
AND T2.GAME ID = 153); 


T2 返回 1 251 009 行 数据 。 现 在 我 们 得 到 信息 , 小 表 T1 C11 799) 与 较 大 表 T2 (1 251 009) 
进行 关联 。 一 般 情 况 下 ， 小 表 与 大 表 关 联 ， 可 以 让 小 表 作为 NL 驱动 表 ， 大 表 走 连接 列 索引 。 
在 确定 能 否 走 NL 之 前 ， 要 先 检查 两 个 表 之 间 的 关系 ， 同 时 检查 表 连 接 列 的 数据 分 布 ， 于 是 我 
们 执行 如 下 SQL。 


96 ”分 页 语句 优化 案例 


SELECT IDFA, COUNT(*) 

FROM SYS ACTIVATION SDK IOS 
GROUP BY IDFA 
ORDER BY 2 DESC; 


我 们 发 现 IDFA 基数 很 低 ， 数 据 分 布 不 均衡 。 因 为 IDFA 基数 很 低 ， 所 以 不 能 让 TI 5 T2 
EREMI, RAEE HASH 连接 。 执 行 计划 中 ，T1 5 T2 本 来 就 是 走 的 HASH 连接 ， 连 接 方 
式 是 正确 的 ,所 以 问题 只 能 出 现在 访问 路 径 上 。T1 走 的 是 INDEXRANGE SCAN, 返 回 了 11 799 
行 数据 , T2 走 的 也 是 INDEX RANGE SCAN, 返回 了 1 251 009 行 数 据 。 INDEX RANGE SCAN 
是 单 块 读 ， 一 般 用 于 返回 少量 数据 ， 这 里 返回 1251009 行 数据 显然 不 合适 ， 因 为 INDEX 
RANGE SCAN 没有 回 表 ， 所 以 应 该 让 其 走 INDEX FASTFULL SCAN。 


SELECT COUNT(DISTINCT IDFA) 
FROM SYS ACTIVATION SDK IOS ТІ 
WHERE CREATE TIME >= TRUNC (sysdate) 
AND CREATE TIME « TRUNC(sysdate) * 1 
AND GAME ID = 153 
AND NOT EXISTS (SELECT /** hash aj іпдйех ffs(E2) */ 
IDFA 
FROM SYS ACTIVATION SDK IOS T2 
WHERE CREATE TIME « TRUNC(sysdate) - 1 
AND T2.GAME ID - 153 
AND Tl.IDFA = T2.IDFA); 


最 终 该 SQL 可 以 在 1 分 钟 内 执行 完毕 。 该 SQL 跑 得 慢 根本 原因 就 是 INDEX RANGE SCAN 
是 单 块 读 。 

为 什么 该 SQL 有 时 要 执行 40 多 分 钟 ,而 有 时 只 需要 执行 几 秒 至 十 来 秒 呢 ? 原因 在 于 buffer 
cache 缓存 。 当 buffer cache 缓存 了 索引 SYS ACTIVATION SDK IOS IDXI, SQL 就 能 在 几 秒 
至 十 几 秒 执行 完毕 ， 如 果 buffer cache 没有 缓存 SYS ACTIVATION SDK IOS_ IDX1， 执 行 计 
划 中 Id-5 走 的 是 INDEX RANGE SCAN， 导 致 大 量 单 块 读 ， 所 以 会 执行 40 分 钟 左右 。 更正 了 
执行 计划 之 后 ， 该 SQL 最 慢 可 以 在 1 分 钟 内 执行 完毕 。 


2013 年 一 唯 品 会 的 朋友 有 如 下 语句 需要 优化 。 


select * 
from (select Ё.* 
from tms.inf b2c djwlzt f f 
inner join tms.orderstatus os on f.transport code - os.statuscode 
where f.warehouse - 'VIP BJ' 
and f. is send - 0 









created dtm loc, os.Sort No 


where ШЕ. ттар 500; š 


该 SQL 类 似 分 页 语句 ， 因 此 我 们 可 以 用 分 页 语句 优化 思路 对 其 进行 优化 。 , 
我 们 首先 应 该 检查 分 页 语句 是 否 符合 分 页 语句 编写 规范 。 这 里 该 SQL 排序 列 来 自 两 个 表 ， 不 
符合 分 页 语句 编写 规范 。 我 们 在 第 8 章 中 讲 到 , 分 页 语句 只 能 对 一 个 表 的 列 进行 排序 。 该 SQL 
排序 列 来 自 f 和 os， 并 且 显 示 的 时 候 只 有 了 表 的 数据 。 因 此 我 们 建议 去 掉 os 表 的 排序 字段 ， 
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к "epus — — 0 ] | | 00 ] — 
如 下 所 示 。 


select + 
from (select f.* 
from tms.inf b2c djwlzt f f 
inner join tms.orderstatus os on f.transport code - os.statuscode 
where f.warehouse = 'VIP BJ' 
and f.is send - 0 


where rown <= 500; | 


排序 列 来 自 f 表 ， 需 要 对 f 表 创建 索引 ， 因 为 过 滤 条 件 是 等 值 访 问 , 我 们 可 以 把 过 滤 条 件 
放 在 前 面 ， 排 序列 放 在 后 面 ， 于 是 创建 如 下 索引 。 


| create index idx f inf on inf b2c djwlzt f(warehouse,is send,created dtm loc); 


然后 强制 f 表 与 os КЖ ЙД, [ШЕ ЕЕ РЧА 50706, ERTER. 


select * 
from (select /*+ use nl(f,os) leading(f) */ 
£ 
from tms.inf b2c djwlzt f f 
inner join tms.orderstatus os on f.transport code - os.statuscode 
where f.warehouse - 'VIP BJ' 
and f.is send = 0 
order by f.created dtm loc) 
where rownum «- 500; 





f.create 


A 9 

执行 计划 如 下 。 

| Id |Operation | Name | Rows | Bytes | Cost (%CPU) | 
| 0 ISELECT STATEMENT | | 500 | 725K| "S4 (1)| 
|* 1 | COUNT STOPKEY | | | | | 
1. 2| VIEW | | 502 | 728К| 54 (1)| 
3:9] NESTED LOOPS | | 502 | 121К| 754” (174 
Іс 4 1 TABLE ACCESS BY INDEX ROWID| ІМЕ B2C DJWLZT F | 2419К| 562M| 71 (0)| 
flint DM INDEX RANGE SCAN | IDX F INF | 502 | | 5 (D) 
6 1 TABLE ACCESS FULL | ORDERSTATUS | 3j 3 | 1 OMI 


Predicate Information (identified by operation id): 


1 - filter (ROWNUM<=500) 
5 - access("F"."WAREHOUSE"-'VIP ВО" AND "F","IS SEND"=0) 
6 - filter("F"."TRANSPORT CODE"-"OS"."STATUSCODE") 


Statistics 


1 recursive calls 
0 db block gets 





2 physical reads 
0 redo size 
67968 bytes sent via SQL*Net to client 
883 bytes received via SQL*Net from client 
35 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
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9.7 ORDER BY 取 别 名 列 优化 案例 


| 500 rows processed 


从 执行 计划 中 我 们 看 到 被 驱动 表 走 了 全 表 扫 描 , РАК 50) 0 НЕЕ 243191101, 必须 
走 索 引 ， 于 是 创建 如 下 索引 。 


І create index STATUSCODE IDX оп ORDERSTATUS (STATUSCODE); 


创建 索引 之 后 的 执行 计划 如 下 。 




















Id |Operation Name Rows Bytes Cost (%СРО) 
0 |SELECT STATEMENT 500 725K Au. QJ 
* 1 | COUNT STOPKEY | | 
| 2 [ VIEW 502 728K 74 (0) 
3. | NESTED LOOPS 502. | 121K ТЕ 40) 
4 | TABLE ACCESS BY INDEX ROWID INF B2C DJWLZT F 2419K 562M 91 (0) 
2:97 1 INDEX RANGE SCAN IDX F INF 502 5 h (0) 
* @ | INDEX RANGE SCAN STATUSCODE IDX i 3 0 (0) 


1 - filter(ROWNUM«-500) 
5 - access("F"."WAREHOUSE"-'VIP ВО! AND "F"."IS SEND"-0) 
6 - access("F"."TRANSPORT CODE"-"OS","STATUSCODE") 








Statistics 
l recursive calls 
0 db block gets 
247 
0 physical reads 


0 redo size 
60433 bytes sent via SQL*Net to client 
883 bytes received via SQLxNet from client 
35 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
500 rows processed 


优化 完毕 之 后 ， 该 SQL 逻辑 读 只 有 247 个 ， 最 终 该 SQL 可 以 秒杀 。 





2017 年 ， 网 络 优化 班 的 学 生 问 怎么 优化 以 下 语句 。 


select rownum as r, a.* 
from (select пра1.АВЕА ID, 
npai.PSO ID, 
npai.RO ID, 
npai.NO, 
npai.ADDR, 








, ІШ Кеки i, 
to char(npai.CMPLT DT, 'yyyy-mm-dd hH24:mi:ss') as CMPLT DT, 
npai.CRM PROD ID, 


npai.PROD SERV SPEC ID, 
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PIP NIE, Те Uu i ree 





npai.PROD SERV SPEC NAME, 
npai.ACTION TP ID, 
npai.ACTION TP NAME 
from NT PSO ARCH INFO npai 
where npai.crtd dt »- to date('2017-01-01', 'yyyy-mm-dd') 
and npai.crtd dt <= to date('2017-02-01', 'yyyy-mm-dd') 
and local area id - 3 
order by crtd dt) а 


where rownum «- 20; 


执行 计划 如 下 。 
Plan hash value: 2467293374 


| Id |Operation IName IRows |Bytes|Cost($CPU) | 
| 0 |SELECT STATEMENT | | 20|28160| 489K (1)| 
|* 3 | COUNT STOPKEY | | | | | 
| 2 | VIEW | | 950К|1276М| 489K (1) | 
|* 3 | SORT ORDER BY STOPKEY | | 950K| 85М| 489K (1)| 
б ЖУ] PARTITION LIST SINGLE | | 950К| 85М| 469K (1)| 
г 9&1] TABLE ACCESS BY LOCAL INDEX ROWID|NT PSO ARCH INFO| 950K| 85М| 469K (1)| 
|ж 5 | INDEX RANGE SCAN |IDX NTPAI CRDT | 950K| ӨӨ (Шу 


1 - filter (ROWNUM<=20) 
3 - filter (ROWNUM<=20) 
6 - access("NPAI"."CRTD DT"2-TO DATE(' 2017-01-01 00:00:00', 'syyyy-mm-dd hh24:mi: 
вв") 
AND "NPAI"."CRTD DT"«-TO DATE('2017-02-01 00:00:00", 'syyyy-mm-dd hh24: 
mi:ss')) 


该 SQL 类 似 分 页 语句 。 拿 到 分 页 语句 ， 我 们 应 该 先 查 看 分 页 语句 是 否 符合 分 页 编码 规范 。 
这 里 ，SQL 完全 符合 分 页 语句 编码 规范 。 

该 SQL 排序 列 是 crtd_dt， 执 行 计 划 中 走 的 也 是 crtd_dt 列 的 索引 。 表 nt pso arch info 是 
LIST 分 区 表 ， 分 区 列 是 local area id， 从 执行 计划 中 〈Id=4) 看 到 只 扫描 了 一 个 分 区 。 按 道理 
该 SQL 不 应 该 出 现 SORT ORDER BY。 为 什么 执行 计划 中 有 SORT ORDER BY 呢 ? 我 们 注意 
MZ, SQL 语句 中 order by 的 列 спа dt 在 select 中 进行 了 to char 格式 化 ， 格 式 化 之 后 取 了 别 
名 , 但 是 别名 居然 与 列 名 一 样 。 正 是 因为 别名 与 列 名 一 样 , 才 导 致 无 法 消除 SORT ORDER BY. 

现在 我 们 另外 取 一 个 别名 〈CRTD DTD. 


select rownum as r, a.* 

from (select npai.AREA ID, 
npai.PSO ID, 
npai.RO ID, 
npai.NO, 
npai.ADDR, 
to char (праї 
to char (npai: T 
npai.CRM PROD ID, 
npai.PROD SERV SPEC ID, 
npai.PROD SERV SPEC NAME, 
npai.ACTION TP ID, 
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npai.ACTION TP NAME 
from NT PSO ARCH INFO npai 
where npai.crtd dt »- to date('2017-01-01', 'yyyy-mm-ad') 
and npai.crtd dt <= to date('2017-02-01', 'yyyy-mm-dd') 
and local area id - 3 


dt) a 





where rownum <= 20; 


我 们 再 次 查看 执行 计划 。 
Plan hash value: 3066843972 






| Xd | Name [Rows |Bytes| Cost($CPU)| 
| 9 STATEMENT | | 20|28160| 489K (1)| 
[5 3 STOPKEY | | | | | 
ПЕС. | | 950K|1276M| 489K (1)| 
I Ж PARTITION LIST SINGLE | | 950К| 85М| 469K (1)| 
| 4| TABLE ACCESS BY LOCAL INDEX ROWID|NT PSO ARCH INFO| 950K|  85M| 469K (1)| 
|ж 5 | INDEX RANGE SCAN |IDX NTPAI CRDT 950K | | 2581 (1 


Predicate Information (identified by operation id): 


1 - filter (ROWNUM<=20) 
,5 - access("NPAI"."CRTD DT"»-TO DATE(' 2017-01-01 00:00:00", 'syyyy-mm-dd hh24:mi 
uiu baga: "CRTD DT"«-TO DATE(' 2017-02-01 00:00:00', 'syyyy-mm-dd hh24:mi:ss')) 
更 改 别名 之 后 ， 消 除了 SORT ORDER BY， 从 而 达到 了 优化 目的 。 为 什么 必须 要 更 改 别名 
ПЕ? 这 是 因为 如 果 不 更 改 别 名 , order by сай dt 就 相当 于 order by 别名 , 也 就 是 order by (о char 
(npai.CRTD DT, 'yyyy-mm-dd hH24:mi:ss)， 而 索引 中 记录 的 是 date 类 型 ， 现 在 排序 变 成 了 按 
照 char 类 型 排序 ， 如 果 不 更 改 别名 执行 计划 就 无 法 消除 SORT ORDER BY。 
在 2014 年 的 时 候 也 遇 到 一 个 类 似 案例 ,但 是 该 案例 SQL 和 执行 计划 太 长 ， 无 法 呈现 在 本 
书 中 。 大 家 如 有 兴趣 ， 可 以 查看 博客 : http://blog.csdn.net/robinson1988/ article/details/40870901 。 


2015 年 ， 网 络 优化 班 的 学 生 问 如 何 优化 以 下 SQL。 


SOL» explain plan for 
2 select gcode,name,idcode,address,noroom,etime from 
3 LY T CHREC t where gcode in ( 
4 select gcode from LY T CHREC t where name-'9K—' and bdate -'19941109') a 
5 


; 





Explained 


SQL» select * from table(dbms xplan.display(null,null, 'ADVANCED -PROJECTION')); 


PLAN TABLE OUTPUT 


Plan hash value: 953100977 
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| Та | Operation | Name | Rows | 
| 0 | SELECT STATEMENT | | 2 | 
I* 1 | HASH JOIN RIGHT SEMI | | 2 | 
|90 E, TABLE ACCESS BY GLOBAL INDEX ROWID| LY T CHREC | i | 
pe 3 | INDEX RANGE SCAN | IDX LY T CHREC NAME | 15 

| 4 | PARTITION HASH ALL | | 200M| 
| Sl TABLE ACCESS FULL | LY T CHREC | 200M| 


1 - SEL$5DA710D3 

2 - SEL$5DA710D3 / TGSEL$S2 
3 - SELS5DA710D3 / TGSELS2 
5 - SELS$5DA710D3 / TGSEL$1 


Outline Data 


BEGIN OUTLINE DATA 
SWAP JOIN INPUTS(8"SEL$5DA710D3" "T"Q"SEL$2") 
USE HASH(8"SEL$5DA710D3" "T"QG"SEL$2") 
LEADING(8"SELS$5DA710D3" "T"G"SELS1" "Т"@"5Е152") 
INDEX RS ASC(8"SELS5DA710D3" "T"@"SEL$2" ("LY T CHREC"."NAME")) 
FULL(G8"SEL$5DA710D3" "т"@"5Е1$1") 
OUTLINE (8"SEL$2") 
OUTLINE (8"SEL$1") 
UNNEST (8 " SEL$2") 
OUTLINE LEAF (8"SEL$5DA710D3") 
ALL ROWS 
DB VERSION('11.2.0.3') 
OPTIMIZER FEATURES ENABLE ('11.2.0.3') 
IGNORE OPTIM EMBEDDED HINTS 
END OUTLINE DATA 

* 

/ 


Predicate Information (identified by operation id): 


1 = access("GCODE"-"GCODE") 
2 - filter("BDATE"-'19941109') 
3 - access ("NAME"=' 张 三 ') 


朋友 提供 的 信息 : 子 查询 返回 一 个 人 开房 的 房 号 记录 ， 共 返回 63 行 。 该 SQL 就 是 查 与 某 
人 相同 的 房间 号 的 他 人 的 记录 。LY T CHREC 表 有 两 亿 条 记录 。 整 个 SQL 执行 了 30 分 钟 还 
没 出 结果 , 子 查询 可 以 秒 出 结果 , ССОРЕ. МАМЕ. IDCODE, ADDRESS. NOROOM. ETIME, 
BDATE 都 有 索引 。 

根据 以 上 信息 我 们 得 出 : 该 SQL EK LY T CHREC 有 两 亿 条 数据 ， 没 有 过 滤 条 件 ，IN 
子 查询 过 滤 之 后 返回 63 行 数据 ， 关 联 列 是 房间 号 СОСОРЕ). ІҮ Т CHREC 应 该 存放 的 是 开 
房 记录 数据 ，GCODE 列 基 数 应 该 比较 高 。 在 本 书 中 我 们 反复 强调 : 小 表 与 大 表 关 联 ， 如 果 大 
表 连 接 列 基数 比较 高 ， 可 以 走 典 套 循 环 ， 让 小 表 驱 动 大 表 ， 大 表 走 连接 列 的 索引 。 这 里 小 表 就 
是 IN 子 查询 ， 大 表 就 是 主 表 ， 我 们 让 IN 子 查询 作为 NL 驱动 表 。 


select /*+ leading(tea) use_nl(t@a,t) */ 

gcode, name, idcode, address, noroom, etime 
from zhxx lgy.LY T CHREC t 

where gcode in (select /%% qb name(a) */ 
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gcode 
from zhxx lgy.LY T CHREC t 
where name = '5K—' 
and bdate = '19941109'); 
最 终 该 SQL 可 以 秒 出 。 






2014 年 ， 一 位 物流 行业 的 朋友 说 以 下 SQL 要 执行 4 个 多 小 时 。 


SELECT "VOUCHER".FID "ID", 
"ENTRIES",.FID "ENTRIES. IDH, 
"ENTRIES". FEntryDC "ENTRIES.ENTRYDC", 
"ACCOUNT".FID "ACCOUNT.ID", 
"ENTRIES".FCurrencyID "CURRENCY.ID", 
"PERIOD".FNumber "PERIOD.NUMBER", 
"ENTRIES".FSeq "ENTRIES.SEQ", 
"ENTRIES".FLocalExchangeRate "LOCALEXCHANGERATE", 
"ENTRIES".FReportingExchangeRate "REPORTINGEXCHANGERATE", 
"ENTRIES".FMeasureUnitlD "ENTRYMEASUREUNIT.ID", 
"ASSISTRECORDS".FID "ASSISTRECORDS.ID", 
"ASSISTRECORDS".FSeq "ASSISTRECORDS.SEQ", 
CASE 
WHEN (("ACCOUNT".FCAA IS NULL) AND 
("ACCOUNT".FhasUserProperty <> 1)) THEN 
"ENTRIES".FOriginalAmount 
М ELSE 
"ASSISTRECORDS".FOriginalAmount 
END "ASSISTRECORDS.ORIGINALAMOUNT", 
CASE 
WHEN (("ACCOUNT".FCAA IS NULL) AND 
("ACCOUNT".FhasUserProperty «» 1)) THEN 
"ENTRIES".FLocalAmount 
ELSE 
"ASSISTRECORDS".FLocalAmount 
END "ASSISTRECORDS.LOCALAMOUNT", 
CASE 
WHEN (("ACCOUNT".FCAA IS NULL) AND 
("ACCOUNT".FhasUserProperty «» 1)) THEN 
"ENTRIES".FReportingAmount 
ELSE 
"ASSISTRECORDS".FReportingAmount 
END "ASSISTRECORDS.REPORTINGAMOUNT", 
CASE 
WHEN (("ACCOUNT".FCAA IS NULL) AND 
("ACCOUNT".FhasUserProperty «» 1)) THEN 
"ENTRIES".FQuantity 
ELSE 
"ASSISTRECORDS".FQuantity 
END "ASSISTRECORDS.QUANTITY", 
CASE 
WHEN (("ACCOUNT".FCAA IS NULL) AND 
("ACCOUNT".FhasUserProperty «» 1)) THEN 
"ENTRIES".FStandardQuantity 
ELSE 
"ASSISTRECORDS".FStandardQuantity 
END "ASSISTRECORDS,.STANDARDQTY", 
CASE 
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жож зо 优化 案例 赏析 





WHEN (("ACCOUNT".FCAA IS NULL) AND 
("ACCOUNT".FhasUserProperty «» 1)) THEN 
"ENTRIES",FPrice 
ELSE 
"ASSISTRECORDS".FPrice 
END "ASSISTRECORDS.PRICE", 
CASE 
WHEN ("ACCOUNT".FCAA IS NULL) THEN 
NULL 
ELSE 
"ASSISTRECORDS".FAssGrpID 
END "ASSGRP.ID" 
FROM T GL Voucher "VOUCHER" 
LEFT OUTER JOIN T BD Period "PERIOD" ON "VOUCHER".FPeriodID = 
"PERIOD",FID 
INNER JOIN T GL VoucherEntry "ENTRIES" ON "VOUCHER".FID = 
"ENTRIES".FBillID 
INNER JOIN T BD AccountView "ACCOUNT" ON "ENTRIES".FAccountID = 
"ACCOUNT".FID 
LEFT OUTER JOIN T GL VoucherAssistRecord "ASSISTRECORDS" ON "ENTRIES".FID = 
"ASSISTRECORDS".FEntryID 





ORDER BY "ID" ASC, 


执行 计划 如 下 。 


0 |SELECT STATEMENT | 13| 5733| 486 (1) | 
1 | SORT ORDER BY | 13| 5733| 486 (1)1 
2 VIEW [УМ NWVW 2 13| 5733| 486 (1) | 
3 HASH UNIQUE | 13|11115| 486 (1)1 
4 NESTED LOOPS OUTER | 13|11115| 485 (1) | 
9 NESTED LOOPS | 9| 6606| 471 (1) | 
6 | 
7 | 
8 | 
9 | 

| 











NESTED LOOPS 9| 6057| 467 (1) | 

MERGE JOIN OUTER | 1| 473| 459 (1) | 

HASH JOIN | 1| 427| 458 (1) | 

NESTED LOOPS | | | 

10 NESTED LOOPS | 258|83850| 390 (0) | 
11 NESTED LOOPS | 6| X332] 3 (0) | 
12 TABLE ACCESS BY INDEX ROWID|T BD ACCOUNTVIEW TIC н A 2 (0) | 

| 13 INDEX UNIQUE SCAN |PK BD ACCOUNTVIEW 1| | 1. (0) | 
14 INDEX RANGE 5САМ |IX BD ACTCOMLNUM 6| 666| 1 (0) | 
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[ 15 INDEX RANGE SCAN IX GL VCHAACCT 489 1 (0) | 
| 16 TABLE ACCESS BY INDEX ROWID |T GL VOUCHERENTRY 42| 4326 65 (0) | 
| 17 INDEX RANGE SCAN IX GL VCH 11 - 7536| 750K 68 (0) | 
| 18 BUFFER SORT Ш 46 391 (0) | 
| 19 | INDEX RANGE SCAN IX PERIOD ENC Т 46 1 (031 
| 20 TABLE ACCESS BY INDEX ROWID T GL VOUCHERENTRY 17| 3400 8 (0) | 
| 21 INDEX RANGE SCAN IX GL VCHENTRYFOI 17 1 (0) 

|42 TABLE ACCESS BY INDEX ROWID T BD ACCOUNTVIEW 1 61 1 (0) | 
1223 INDEX UNIQUE SCAN PK BD ACCOUNTVIEW 1 k (0) 

| 24 TABLE ACCESS BY INDEX ROWID |Т GL VOUCHERASSISTRECORD 1 121 2 (0) | 
| 25 INDEX RANGE SCAN |IX GL VCHASSREC 11 2 L (0) | 
Note 


- 'PLAN TABLE' is old version 


执行 计划 中 居然 是 'PLAN TABLE' is old version， 无 法 看 到 谓词 信息 ， 这 需要 重建 
PLAN_TABLE。 因 为 没有 谓词 信息 ， 所 以 就 不 打算 从 执行 计划 入 手 优 化 SQL 了 ， 而 是 选择 直 
接 分 析 SQL， 从 SQL 层面 优化 。 

SQL 语句 中 ，select 到 from 之 间 没 有 标量 子 查 询 ， 没 有 自 定义 函数 ，from 后 面 有 5 个 表 
关联 ，where 条 件 中 只 有 一 个 in TEW), KWAHERI. SOL 语句 中 用 到 的 表 大 小 如 
图 9-8 所 示 。 





` 1 T BD ACCOUNTVIEW DEPPON2011 1466547 1466547 04-ЈАМ-14 23:31:43 
2 T BD PERIOD | DEPPON2011 . 134, 134 05-JAN-14 00:05:24 
3 T GL VOUCHER ^. DEPPON2011 ^ 3578789 3578789 08-JAN-1423:49:42 
4 T GL VOUCHERASSISTRECORD DEPPON2011 86095467 86095467 05-ЈАМ№-14 07:37:22 
5 T GL VOUCHERENTRY DEPPON2011 61165543 61165543 05-JAN-14 08:34:32 

图 9-8 


SQL 语句 中 有 4 个 表 都 是 大 表 ， 只 有 一 个 表 T BD PERIOD 是 小 表 ， 在 SQL 语句 中 与 
T GL VOUCHER 外 关联 ， 是 外 连接 的 从 表 。 如 果 走 骨 套 循环 , T BD PERIOD 只 能 作为 被 驱 
动 表 ， 因 此 排除 了 让 小 表 T_BD_PERIOD 作为 棋 套 循环 驱动 表 的 可 能 性 。 如 果 该 SQL 没有 过 
WR, UE SQL 只 能 走 HASH 连接 。 

SQL 语句 中 唯一 的 过 滤 条 件 就 是 in( 子 查询 ), 因此 只 能 把 优化 SQL 的 希望 寄托 在 子 查询 
ЯЕ. in СРЯ) 与 表 T GL VOUCHER 进行 关联 ，T_GL VOUCHER 同时 也 是 外 连接 的 
EKR, 如果 in (TAH) ВЕЕ Т СІ, УООСНЕК 大 量 数 据 , 那么 可 以 让 T_GL VOUCHER 
作为 散 套 循环 驱动 表 , 一 直 与 后 面 的 表 NL 下 去 ， 这 样 或 许 能 优化 SQL。 如 果 in Cf i) 不 
能 过 滤 掉 大 量 数据 ， 那 么 SQL 就 无 法 优化 ， 最 终 只 能 全 走 HASH. WA in (TEW) 返回 多 
少 行 ， 运 行 多 久 ， 得 到 反馈 : in TAW) 返回 16 880 条 数据 ， 耗 时 23 秒 。 于 是 我 们 将 SQL 
改写 为 with as 子 句 ， 而 且 固化 (/*+ materialize */) with as 子 查 询 ， 让 with as 子 句 作为 在 套 循 
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Е sas E ш... 
环 驱动 表 。 


with x as ( 
SELECT /**)materialize */  "VOUCHER".FID "ID" 
FROM T GL Voucher "VOUCHER" 
INNER JOIN T GL VoucherEntry "ENTRIES" ON "VOUCHER".FID = 
"ENTRIES".FBillID 
INNER JOIN T BD AccountView "ACCOUNT" ON "ENTRIES".FAccountID - 
"ACCOUNT".FID 
INNER JOIN t bd accountview PAV ON ((INSTR("ACCOUNT".flongnumber, 
pav.flongnumber) - 1 AND 
pav.faccounttableid - 
"ACCOUNT".faccounttableid) AND 
pav.fcompanyid - 
"ACCOUNT",fcompanyid) 
WHERE (("VOUCHER".FCompanyID IN ('fSSF82rRSKexM3KKNldOtMznrtQ-')) AND 
(("VOUCHER".FBizStatus IN (5)) AND 
((("VOUCHER".FPeriodID IN ('*wOxkBFVRiKnV7OniceMDoI4jEw-')) AND 
"ENTRIES".FCurrencyID - 
'dfd38d11-00fd-1000-e000-1ebdc0a8100dDEB58FDC') AND 
(pav.FID IN ('vyPiKexLRXiyMb41VSVVzJ2pmCY-'))))) 
) 
SELECT "VOUCHER".FID "ID", 
"ENTRIES".FID "ENTRIES.ID", 
"ENTRIES".FEntryDC "ENTRIES.ENTRYDC", 
"ACCOUNT".FID "ACCOUNT.ID", 
"ENTRIES".FCurrencyID "CURRENCY.ID", 
"PERIOD".FNumber "PERIOD.NUMBER", 
"ENTRIES".FSeq "ENTRIES.SEQ", 
"ENTRIES".FLocalExchangeRate "LOCALEXCHANGERATE", 
"ENTRIES".FReportingExchangeRate "REPORTINGEXCHANGERATE", 
"ENTRIES".FMeasureUnitID "ENTRYMEASUREUNIT.ID", 
"ASSISTRECORDS".FID "ASSISTRECORDS.ID", 
"ASSISTRECORDS",.FSeq "ASSISTRECORDS.SEQ", 
CASE 
WHEN (("ACCOUNT".FCAA IS NULL) AND 
("ACCOUNT".FhasUserProperty <> 1)) THEN 
"ENTRIES".FOriginalAmount 
ELSE 
"ASSISTRECORDS".FOriginalAmount 
END "ASSISTRECORDS.ORIGINALAMOUNT", 
CASE 
WHEN (("ACCOUNT".FCAA IS NULL) AND 
("ACCOUNT".FhasUserProperty «» 1)) THEN 
"ENTRIES".FLocalAmount 
ELSE 
"ASSISTRECORDS".FLocalAmount 
END "ASSISTRECORDS.LOCALAMOUNT", 
CASE 
WHEN (("ACCOUNT".FCAA IS NULL) AND 
("ACCOUNT".FhasUserProperty <> 1)) THEN 
"ENTRIES".FReportingAmount 
ELSE 
"ASSISTRECORDS".FReportingAmount 
END "ASSISTRECORDS.REPORTINGAMOUNT", 
CASE 
WHEN (("ACCOUNT".FCAA IS NULL) AND 
("ACCOUNT".FhasUserProperty «» 1)) THEN 
"ENTRIES".FQuantity 
ELSE 
"ASSISTRECORDS".FQuantity 
END "ASSISTRECORDS.QUANTITY", 
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CASE 
WHEN (("ACCOUNT".FCAA IS NULL) AND 
("ACCOUNT".FhasUserProperty <> 1)) THEN 
"ENTRIES".FStandardQuantity 
ELSE 
"ASSISTRECORDS".FStandardQuantity 
END "ASSISTRECORDS.STANDARDQTY", 
CASE 
WHEN (("ACCOUNT".FCAA IS NULL) AND 
("ACCOUNT".FhasUserProperty <> 1)) THEN 
"ENTRIES".FPrice 
ELSE 
"ASSISTRECORDS".FPrice 
END "ASSISTRECORDS.PRICE", 
CASE 
WHEN ("ACCOUNT".FCAA IS NULL) THEN 
NULL 
ELSE 
"ASSISTRECORDS".FAsSGrpID 
END "ASSGRP.ID" 
FROM T GL Voucher "VOUCHER" 
LEFT OUTER JOIN T BD Period "PERIOD" ON "VOUCHER".FPeriodID - 
"PERIOD".FID 
INNER JOIN T GL VoucherEntry "ENTRIES" ON "VOUCHER".FID = 
ç "ENTRIES".FBillID 
INNER JOIN T BD AccountView "ACCOUNT" ON "ENTRIES".FAccountID - 
"ACCOUNT".FID 
LEFT OUTER JOIN T GL VoucherAssistRecord "ASSISTRECORDS" ON "ENTRIES".FID - 
"ASSISTRECORDS".FEntryID 






""ENTRIES.SEQ" ASC, "ASSISTRECORDS.SEQ" ASC; 


改写 后 的 执行 计划 如 下 。 


ORDER BY "ID" ASC, 


O|SELECT STATEMENT 

1| TEMP TABLE TRANSFORMATION 
2| LOAD AS SELECT 

31 НА5Н JOIN 


| 

| 

| 

| 

М NESTED LOOPS | | 
| 5l NESTED LOOPS | | 
| 6| NESTED LOOPS | 

(в 95 TABLE ACCESS BY INDEX ROWIDIT BD АССООМТУТЕН | 
| 8| INDEX UNIQUE SCAN |PK BD ACCOUNTVIEW | 
| 9| INDEX RANGE SCAN |IX BD ACTCOMLNUM | 
| 101 INDEX RANGE SCAN |IX GL VCHAACCT | 
ГЕНІ TABLE ACCESS BY INDEX ROWID |Т GL VOUCHERENTRY | 
| 12| INDEX RANGE SCAN |IX GL VCH 11 | 
| 13] SORT ORDER BY | | 
| 14| NESTED LOOPS OUTER | | 
| 151 NESTED LOOPS | | 
| 161 NESTED LOOPS | | 
| 171 NESTED LOOPS OUTER | | 
| 18| NESTED LOOPS | | 
| 19| VIEW [УЯ NSO 1 | 
| 201 HASH UNIQUE | | 
(727) VIEW | | 
| 221 TABLE ACCESS FULL |SYS TEMP OFD9D6853 1AD5C99D| 
| 231 INDEX RANGE SCAN |IX GL VCH FIDCMPNUM | 


| | 
|SYS_TEMP_0FD9D6853_1AD5C99D| 
| | 


24|11208| 506 


1| 415) 

| | 
258|83850| 
6| 1332| 
I4 DLL] 
1| | 
6| 666| 
489| | 
42| 4326| 
7536| 662К| 
24|11208| 
24|11208| 
17| 6086| 
17| 5253| 
21,121! 
l| 2787) 
1| 29| 
1| 24| 
1| 24| 
1| 29| 
71 58 | 


458 


(1) | 
| 
| 

(1) | 
| 

(0)| 

(0) 1 

(0) | 

(0) | 

(0) | 

(0) | 

(0) | 

(0) | 

(5) 1 

(3) | 


19r 


N c0 0 050 0 00000 0. 


| 24| INDEX RANGE SCAN |IX PERIOD ENC | 11 344 1 (0)1 
| 25] TABLE ACCESS BY INDEX ROWID|T GL VOUCHERENTRY | 17| 3196| 8 (0) 
| 26| INDEX RANGE SCAN |ІХ GL УСНЕМТАҮЕО1 j= 17] | Y (07! 
| 27| TABLE ACCESS BY INDEX ROWID |T BD ACCOUNTVIEW | 1| 491 1 (01 
| 28| INDEX UNIQUE SCAN | PK BD ACCOUNTVIEW | 1| | 1 (0)l 
| 29| TABLE ACCESS BY INDEX ROWID |Т GL VOUCHERASSISTRECORD | 1| 109| 2 (01 
| 301 INDEX RANGE SCAN |IX GL VCHASSREC 11 | 21 | 1 (0) 


将 SQL 改写 之 后 ， 能 在 1 分 钟 内 执行 完毕 ， 最 终 SQL 返回 42 956 条 数据 。 

为 什么 要 将 in 子 查询 改写 为 with as WE? 这 是 因为 原始 SQL F, in 子 查询 比较 复杂 , 想 直 
接 使 用 HINT 让 in 子 查询 作为 髓 套 循环 驱动 表 反 向 驱 动 主 表 比 较 困 难 ， 所 以 将 in 子 查 询 改写 
为 with as。 需 要 注意 的 是 with as 子 句 中 必须 要 添加 HINT:/*+ materialize */， 同 时 主 表 与 子 查 
询 关 联 列 必须 有 索引 ， 如 果 不 添加 HINT: /*+ materialize */， 如 果 主 表 与 子 查 询 关 联 列 没 有 索 
引 ， 优 化 器 就 不 会 自动 将 with as AREMARK. with as 子 句 添加 了 /*+ materialize */ 会 
生成 一 个 临时 表 ， 这 时 ， 就 将 复杂 的 in 子 查 询 简单 化 了 ， 之 后 优化 器 会 将 with as 子 句 展开 
(unnesting)， 将 子 查询 展开 一 般 是 子 查询 与 主 表 进 行 HASH 连接 ， 或 者 是 子 查 询 作 为 嵌 套 循 
环 驱 动 表 与 主 表 进 行 关联 , 一 般 不 会 是 主 表 作为 撕 套 循环 驱动 表 ,， 因为 主 表 作 为 骨 套 循环 驱动 
表 可 以 直接 走 Filter， 不 用 展开 。 优 化 器 发 现 with as 子 句 数据 量 较 小 ， 而 主 表 较 大 ， 而 且 主 表 
连接 列 有 索引 ， 于 是 自动 让 with as 子 句 固化 的 结果 作为 了 甘 套 循环 驱动 表 。 


e : 


UE 
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2016 4E, 一 互联 网 彩票 行业 的 朋友 说 以 下 SQL 要 跑 几 十 分 钟 (数据 库 环境 Oraclel lgR2)« 


select count(distinct a.user name), count(distinct a.invest id) 
from base data login infoGagent а 
where a.str day «- '20160304' 
and a.str day »- '20160301' 
and a.channel id in (select channel rlat 
from tb user channel a, tb channel info b 
where a.channel id - b.channel id 
and a.user id - 5002) 
and a.platform = a.platform; 


Plan hash value: 2367445948 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| 
| 0 | SELECT STATEMENT | | 1 | 130. | 754 (231 
І 1| SORT GROUP BY | | 174 180. | І 
pe 72-1 НА5Н JOIN | | 4067K| 504M| 754 (2) | 
ЖА 3%) HASH JOIN | | 21835 | 360K| 258 (1 
|4” 4-1 TABLE ACCESS FULL| ТВ USER CHANNEL | 11528 | 157K| 19 (0) | 
| 5. | TABLE ACCESS FULL| TB CHANNEL INFO | LEREZ d 206K| 238 (0) | 
f - 634 REMOTE ША | BASE DATA LOGIN INFO |  190K| 17M] 486 (1)| 
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按 道理 说 不 应 该 执行 儿 十 分 钟 ， 正 


940 连接 列 数据 分 布 不 均衡 导致 性 能 问题 


2 - access("A"."CHANNEL ID"-"CHANNEL RLAT") 
3 - access("A"."CHANNEL ID"-"B"."CHANNEL ID") 
4 - filter("A"."USER ID"-5002) 


Remote 501 Information (identified by operation id): 


6 - SELECT "USER NAME","INVEST ID","STR DAY","CHANNEL ID","PLATFORM" 
"BASE DATA · LOGIN INFO" "A" WHERE "STR | DAY"«-'20160304' AND "STR DAY"»-'20160301' 


AND "PLATFORM" IS NOT NULL (accessing 'AGENT' ) 


想 要 优化 SQL. 必须 要 知道 表 大 小 .TB USER CHANNEL 有 1 万 行 数据 ,TB_ CHANNEL - 
INFO 有 1 万 行 左右 ，BASE DATA LOGIN INFO 有 19 万 行 ， 过 滤 之 后 剩 下 4 万 行 左 右 。 执 
行 计划 走 的 是 HASH 连接 ， 每 个 表 都 只 扫描 一 次 ， 虽 然 是 全 表 扫 描 ， 但 是 最 大 表 才 19 万 行 ， 

常情 况 下 应 该 可 以 1 秒 左右 出 结果 。 起 初 我 们 怀疑 是 SQL 
中 DBLINK 传输 数据 导致 性 能 问题 ， 于 是 在 本 地 创建 一 个 一 模 一 样 的 表 , 但 是 该 SQL 还 是 执 


行 缓慢 。 


我 们 只 能 一 步 一 步 排查 SQL 哪里 出 了 问题 ， 让 朋友 执行 如 下 SQL。 


select count(*) --- 改 动 了 这 里 
from base data login_info@agent a 
where a.str day «- '20160304' 
and a.str day »- '20160301' 
and a.channel id in (select channel rlat 
from tb user channel a, tb channel info b 
where a.channel id - b.channel id 
and a.user id - 5002) 
and a.platform - a.platform; 


上 面 SQL 可 以 秒 出 。 于 是 朋友 继续 执行 如 下 SQL. 


select count(a.user name) --- 改 动 了 这 里 
from base data login info@agent a 
where a.str day «- '20160304' 
and a.str day »- '20160301' 
and a.channel id in (select channel rlat 
from tb user channel a, tb channel info b 
where a.channel id - b.channel id 
and a.user id - 5002) 
and a.platform = a.platform; 


上 面 SQL 也 可 以 秒 出 。 我 们 继续 排查 。 


select count(a.user name), count(a.invest id) ---- 改 动 了 这 里 
from base data login infoGagent a 
where a.str day <= '20160304' 
and a.str day »- '20160301' 
and a.channel id in (select channel rlat 
from tb user " channel a, tb channel info b 
where a.channel _id = b.channel id 
and a. user id - 5002) 
and a.platform - a.platform; 


以 上 SQL 还 是 可 以 秒 出 ， 我 们 继续 排查 。 


select count (distinct a.user name), count(a.invest id) --- 改 动 了 这 里 
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DEN па UL = 


from base data login info8agent а 
where a.str day <= '20160304' 
and a.str day >= '20160301' 
and a.channel id in (select channel rlat 
from tb user channel a, tb channel info b 
where a.channel id - b.channel id 
and a.user id - 5002) 
and a.platform = a.platform; 


EH SQL 依然 可 以 秒 出 。 现在 我 们 找到 引起 SQL 慢 的 原因 了 ,select 中 同时 count(distinct 
a.user name), count(distinct а.іпуеѕі id) 导致 SQL 查询 缓慢 。 
在 实际 工作 中 ， 要 优先 解决 问题 ， 再 去 查找 问题 的 根本 原因 。 我 们 将 SQL 进行 如 下 改写 。 


with tl as 
(select КЕШЕ ШЕТ 
a.user name, a.invest id 
from base data login іпҒоҝадепі a 
where a.str day «- '20160304' 
and a.Str day >= '20160301' 
and a.channel id in (select channel rlat 
from tb user channel a, tb channel info b 
where a.channel id - b.channel id 
and a.user id - 5002) 
and a.platform = a.platform) 
select count (distinct user name) ,count(distinct invest id) from tl; 


为 什么 改写 成 以 上 SQL 能 解决 性 能 问题 呢 ? 因为 在 排查 问题 的 时 候 count 不 加 distinct 是 
可 以 秒 出 的 , 所 以 我 们 先 将 能 秒 出 的 SQL 放 到 with as 子 句 , 通过 添加 HINT: /*+ materialize */ 
生成 临时 表 ， 再 对 临时 表 进 行 count(distinct...),count(distinct)， 这 样 就 能 解决 问题 。 改 写 后 的 
SQL 执行 计划 如 下 。 
Plan hash value: 901326807 























Id |Operation Name Rows Bytes|Cost (%CPU) 

0 |SELECT STATEMENT | 1 54 X521 (L) 

1 ТЕМР TABLE TRANSFORMATION | | 

2 | LOAD AS SELECT SYS TEMP 0FD9D6720 EB8EA | 
* 3 HASH JOIN RIGHT SEMI 190K 22M 744 (1) 
EC VIEW VW NSO 1 11535 | 304K| 258 (1)| 
ж HASH JOIN {+ 11535 | 360K 258 (1) 
* 6 TABLE ACCESS FULL TB USER CHANNEL 11535 | 157К I9 (0) 
| Т TABLE ACCESS FULL TB CHANNEL INFO 11767 206K 238 (0) 
| 8 REMOTE BASE DATA LOGIN INFO 190K 17M 486 (1) 

9 SORT GROUP BY 1 54 

10 | VIEW | 190К 9M 878 (1) 

11 TABLE ACCESS FULL SYS TEMP 0FD9D6720 ЕВВЕА 190K| 9M 878 (1) 


3 - access("A"."CHANNEL ID"-"CHANNEL RLAT") 
5 = access("A"."CHANNEL ID"-"B","CHANNEL ID") 
6 = filter("A"."USER ID"-5002) 


Remote SQL Information (identified by operation id): 


910 ”连接 列 数据 分 布 不 均衡 导致 性 能 问题 


8 - SELECT "USER NAME","INVEST ID","STR DAY","CHANNEL ID". "PLATFORM" FROM "BASE DA 
TA LOGIN INFO" 


"A" WHERE "STR DAY"«-'20160304' AND "STR DAY"»-'20160301' 
AND "PLATFORM" IS NOT NULL (accessing 'AGENT' ) 


解决 问题 之 后 ， 现 在 我 们 来 查找 SQL 缓慢 的 根本 原因 。 现 在 对 比 缓慢 SQL 的 执行 计划 与 
Жин SQL 的 执行 计划 ， 缓 慢 SQL 的 执行 计划 如 下 。 














| Id | Operation | Name | Rows Bytes | Cost ($CPU)| 

| 0 | SELECT STATEMENT | | Ë 130 | 754 (2) | 

| 1 | SORT GROUP BY | | tiil 130 | | 

[w 2 || HASH JOIN | | 4067K 504M| 754 (2)1 

[S m. 1] HASH JOIN i 115355] 360K| 258 (1)4 

ж 4) TABLE ACCESS FULL| TB_USER_CHANNEL | 215275” 1 157К| 19 (0) | 

| 92 | TABLE ACCESS FULL| TB CHANNEL INFO | 11767 1 206K| 238 (0)1 

| 6 | REMOTE | BASE DATA LOGIN INFO | 190K 17М| 486 (191 
秒 出 SQL 的 执行 计划 如 下 。 

| Id |Operation | Name | Rows Bytes |Cost($CPU) 

| 0 |SELECT STATEMENT | 44 1 54 | 1621 (%1)| 

| 1 | TEMP TABLE TRANSFORMATION | | | | 

| 2 | LOAD AS SELECT |SYS TEMP 0Ер9р6720 EB8EA| 

i5 3 | HASH JOIN RIGHT SEMI | | 190K| 22M| 744 (1)| 

| 41 VIEW VW NSO 1 | "S35. 1 304K| 258 (1)| 

|9521 HASH JOIN | 11535 360K| 258 (1))| 

[* 6 | TABLE ACCESS FULL TB USER CHANNEL | 11835 157К| 187 “(0) 

>“ ЛЗ) TABLE ACCESS FULL TB CHANNEL INFO | 11787. 206K| 238 (0) 

[rogat REMOTE BASE DATA LOGIN INFO | 190K| 17M| 486 (1)| 

| 9 | -SORT GROUP BY | | 1 54 | | 

| 9.1 VIEW | | 190К 9M| 878  (1)| 

| ЛҮ TABLE ACCESS FULL |SYS TEMP 0FD9D6720 EB8EA| 190K| 9M] 878 (1)! 


我 们 注意 仔细 对 比 执行 计划 ， 缓 慢 SQL 执行 计划 中 14-2 是 HASH JOIN， 而 秒 出 SQL 的 
执行 计划 中 14-3 是 HASH JOIN RIGHT SEMI. SEMI 是 半 连 接 特 有 关键 字 ， 绥 慢 SQL 的 执行 
计划 中 没有 SEMI 关键 字 ， 这 说 明 СВО 将 半 连 接 等 价 改 写成 了 内 连接 ; 秒 出 SQL 的 执行 计划 
有 SEMI 关键 字 ， 这 说 明 СВО 没有 将 半 连 接 等 价 改写 成 内 连接 。 现 在 我 们 得 到 结论 ， 该 SQL 
查询 缓慢 是 因为 CBO 内 部 将 半 连 接 改写 为 内 连接 导致 。 

大 家 还 记得 半 连 接 与 内 连接 接 区 别 吗 ? 半 连 只 返回 一 个 表 的 数据 , 关联 之 后 数据 量 不 会 翻 
番 ， 内 连接 表 关 联 之 后 数据 量 可 能 会 翻番 。 该 SQL 查询 缓慢 是 被 改 成 内 连接 导致 ， 现 在 我 们 
有 充分 理由 怀疑 内 连接 关联 之 后 返回 的 数据 量 太 大 , 因为 如 果 关 联 返 回 的 数据 量 很 少 是 不 可 能 
出 性 能 问题 的 。 于 是 检查 两 个 表 连 接 列 的 数据 分 布 。 


select channel id, count(*) 
from base data login info 

group by channel id 

order by 2; 
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Одена C Cei DRESS 
in 子 查询 关联 列 数 
select channel rlat, count(*) 
from tb user channel a, tb channel info b 
where a.channel id - b.channel id 
and a.user id - 5002 


group by channel rlat 
order by 2 desc; 


channel rlat count (*) 





002n2 

023a2 
007s001022001 
007s001022002 
0075001024007 
0075001024009 
0075001022009 
0015001006 
0015001008 
0015001001001 
0018001001003 
0015001001007 
001s001001014 
007s001018003 
0075001018007 
0075001019005 
0075001019008 
0015001002011 
0075001011003 
0075001034 
0075001023005 


两 表 的 数据 分 布 果 然 有 问题 , 其 中 026h2 这 条 数据 倾斜 特别 明显 。 如 果 让 两 表 进 行内 连接 ， 
026h2 这 条 数据 关联 之 后 返回 结果 应 该 是 160162*10984， 现 在 我 们 终于 发 现 该 SQL 执行 缓慢 
的 根本 原因 ， 是 因为 两 个 表 的 连接 列 中 有 部 分 数据 倾斜 非常 严重 。 


Bp ҥкҥ+ ҥн ҥн ҥнҥн н ҥн ҥнҥн нура нэ ра вэ нз № бу 


196 


9.10 连接 列 数据 分 布 不 均衡 导致 性 能 问题 


最 初 采 用 的 是 with as 子 名 加 /*+ materialize */ 临 时 解决 SQL 的 性 能 问题 , 我 们 也 可 以 使 用 
rownum 优化 SQL，rownum 可 以 让 一 个 查询 被 当成 一 个 整体 。 


with tl as 
(select 
a.user name, a.invest id 
from base data login infoGagent a 
where a.str day <= '20160304' 
and a.str day »- '20160301' 
and a.channel id in (select channel rlat 
from tb user channel a, tb channel info b 
where a.channel id - b.channel id 
and a.user id = 5002) 
and a.platform = a.platform апа rownum»0) 
select count(distinct user name) ,count(distinct invest id) from tl; 


如 果 大 家 想 模拟 本 案例 ， 可 以 跟着 下 面 实验 步骤 执行 《请 在 11g 中 模拟 )。 
我 们 先 创建 如 下 两 个 测试 表 。 


create table а as select * from dba objects; 
create table b as select * from dba objects; 


要 执行 的 缓慢 的 SQL 如 下 。 
select count(distinct owner), count(distinct object name) 
from a 
where owner in (select owner from b); 
优化 改写 之 后 的 SQL 如 下 。 
with 七 as(select owner, object name 
from a 


where owner in (select owner from b) 
and rownum > 0) 
select count(distinct owner), count(distinct object name) 
from t; 


我 们 也 可 以 对 子 查 询 先 去 重 ， 将 子 查 询 变 成 1 的 关系 ， 这 样 也 能 优化 SQL. 


select count(distinct owner), count(distinct object name) 
from a 
where owner in (select owner from b group by owner); 


请 思考 为 什么 Oraclellg СВО 会 将 SQL 改写 为 内 连接 ? 大 家 是 否 还 记得 第 5.6.1 节 内 容 ? 

select ... from 1 的 表 where owner in (select owner from п 的 表 ) 改 写 为 内 连接 ， 需 要 加 
distinct。 

select... from п 的 表 where owner in (select owner from 1 的 表 ) 改 写 为 内 连接 ， 不 需要 加 
distinct。 

我 们 的 SQL 是 select count(distinct ),count(distinct)， 所 以 CBO 直接 将 SQL 改写 为 select 
count(distinct a.owner),count(distinct object name) from a,b where a.owner=b.owner; 这 个 问题 在 
12c 中 已 得 到 纠正 。 最 后 我 们 想 说 的 就 是 ， 不 管 以 后 优化 器 进步 有 多 大 ， 我 们 始终 不 能 依赖 优 
化 器 ， 唯 一 可 以 依靠 的 就 是 自己 所 掌握 的 知识 。 
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2012 年 ， 一 朋友 发 来 信息 说 以 下 SQL 要 跑 5 个 小 时 ， 请 求 优化 。 
SELECT 
B.AREA_ID, 
A.PARTY_ID, 
B.AREA_NAME, 
C.NAME CHANNEL NAME, 
B.NAME PARTY NAME, 
B.ACCESS NUMBER, 
B.PROD SPEC, 
B.START DT, 
A.BO ACTION NAME, 
A.SO STAFF ID, 
A.ATOM ACTION ID, 
A.PROD ID 
FROM DW CHANNEL с, 
DW CRM DAY USER B, 
DW BO ORDER A 
WHERE  A.PROD ID = B.PROD ID AND 
A.CHANNEL ID = C.CHANNEL ID AND 
A.SO STAFF ID LIKE '36$' AND 
A.BO ACTION NAME IN (' 新 装 '，' 移 机 '，' 资 费 变更 ') AND 
B.PROD SPEC ІМ (" 普 通电 话 "， 'ADSL','LAN', ' 手 机 '， 
'E8 - 2S'，'E6 移 动 版 '，'"E9 版 1M( 老 版 ) '， 
"普通 E9"，" 普 通 新 版 E8' ， 
' 全 省 紧密 融合 型 E9 套餐 产品 规格 ' ， 
' (新 ) 全 省 紧密 融合 型 E9 套餐 产品 规格 ' ， 
:新 春 欢乐 送 之 ЕВ 套餐 '， 
' 新 春 欢乐 送 之 EG 套餐 ') AND 
NOT EXISTS (SELECT * 
FROM DW BO ORDER D 
WHERE D.STAFF ID LIKE '36%' AND 
A.PARTY ID - D.PARTY ID AND 
A.BO ID !- D.BO ID AND 
A.PROD ID != D.PROD ID AND 
A.BO ACTION NAME IN 
('#Ж', “Ж, 资费 变更 ') AND 


A.COMPLETE DT - INTERVAL '7' DAY < D.COMPLETE DT); 


执行 计划 如 下 。 

Plan hash value: 2142862569 

| Id |Operation IName | Rows | Bytes | Cost (%СРО)| Time 

| 0 |SELECT STATEMENT | | 905 | 121K| 415286  (2)] 13:50:32 | 
|* 1] EIBTER | | | | | | 
|* 2 | HASH JOIN | | 905 | 121К| 12616 (2)] 00:02:32 | 
E 3. T HASH JOIN 1 | 905 | 99550 | 12448 (2) | 00:02:30 | 
| 4| PARTITION RANGE ALL| | 1979; | 108K| 9168 (2)| 00:01:51 | 
|* ЖО TABLE ACCESS FULL|DW BO ORDER | 1979 | 108K| 9168 (2) ] 00:01:51 
1*6] TABLE ACCESS FULL |DW CRM DAY USER| 309K| 15M| 3277 (2)| 00:00:40 | 
m TABLE ACCESS FULL  |DW CHANNEL | 48425 | 1276К| 168 Ui 00:00:03 | 
1* 8 | FILTER | | | | | | 
UE: PARTITION RANGE ALL| | d 1] 29 [- 9147 (2)| 00:01:50 | 
9: | TABLE ACCESS FULL |DW BO ORDER | 175 29 | 9147 (2) | 00:01:50 | 
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9.11 Filter 优化 经 典 案例 


l - filter( NOT EXISTS (SELECT /*+ */ 0 FROM "DW BO ORDER" "D" WHERE (:B1=' 新 装 ' OR :В2=' 
移 机 'OR :B3=' 资 费 变更 ') AND "D"."PARTY ID"-:B4 AND TO CHAR("D"."STAFF ID") 
LIKE 
'36%' AND "D"."COMPLETE DT">:B5-INTERVAL'+07 00:00:00' DAY(2) TO SECOND 
(0) AND 
"D"."PROD ID"<>:B6 AND "D"."BO Ір"<>:В7)) 
2 - access("A"."CHANNEL ID"-"C"."CHANNEL ID") 
3 - access("A"."PROD ID"-"B"."PROD ID") 
5 - filter("A"."PROD ID" IS NOT NULL AND ("A"."BO ACTION NAME"= "新 装 ” OR 
"A"."BO ACTION МАМЕ"- "ЖАЛ, Оң "A"."BO ACTION NAME"= 1 资费 变更 ') AND 
TO CHAR("A"."SO STAFF ID") LIKE '36$') 
6 - filter("B"."PROD SPEC"-'(35) 全 省 紧密 融合 型 E9 套餐 产品 规格 ' OR "B"."PROD SPEC" 


='ADSL' 
OR "B"."PROD_SPEC"='E6 移动 版 ' OR "B"."PROD_SPEC"='E8 - 2S' OR 
"B"."PROD SPEC"-'E9 版 1M( Ж 版 )' OR "B"."PROD SPEC"='LAN' OR "В". 
"PROD SPEC"-' 
普通 E9' OR "B"."PROD SPEC"=" 普 通电 话 ' OR "B"."PROD ЅРЕС"=' ЎТ Е8' OR 
"B"."PROD_SPEC"=' 全 省 _ 紧密 融合 型 E9 套餐 产品 规格 ' OR "B"."PROD SPEC"=! 手 机 
' OR 


"B"."PROD_SPEC"=' 新 春 欢乐 送 之 EG 套餐 ' OR "B"."PROD SPEC"=' 新 春 欢乐 送 之 E8 套餐 ' ) 
8 - filter(:Bl=' 新 装 ”OR :в2- ЖОЛ! OR :B3=' 资 费 变 更 ') 
10 - filter("D"."PARTY ID"-:Bl AND TO CHAR("D"."STAFF ID") LIKE '36%' AND 
"D"."COMPLETE DT"2:B2-INTERVAL'4«07 00:00:00' DAY(2) TO SECOND(0) AND 
"D"."PROD ID"<>:B3 AND "D"."BO ID"<>:B4) 


优化 SQL， 必须 看 表 大 小 ， 表 大 小 信息 如 下 。 
SQL» select count(*) from dw bo order; ----200 万 行 数 据 


COUNT (*) 


2282548 


SQL» select count(*) from dw crm day user; ----40 万 行 数据 


COUNT (*) 


420918 


SQL» select count(*) from dw channel; ---4 万 行 数据 


COUNT (*) 


SQL 语句 中 最 大 表 DW_BO_ORDER 才 200 万 行 数据 ， 但 是 SQL 执行 了 5 个 多 小 时 ， 显 
然 执 行 计 划 有 问题 。 执 行 计 划 中 ，Id=1 是 Filter, ПІН Filter 对 应 的 谓词 信息 有 EXISTS (TA 
询 :B1)， 这 说 明 该 Filter 类 似 嵌 套 循 环 。Id=2 和 Id-8 是 Id-1 的 儿子 ， 因 为 这 里 的 Filter 类 似 
КЕ ЕЖ, 14-2 就 相当 于 NL 驱动 表 ，Id=8 相当 于 NL 被 驱动 表 ，Id=8 是 全 表 扫 描 过 滤 后 的 
数据 ， 所 以 Id=8 可 以 看 作 全 表 扫 描 。 本 书 反 复 强 调 过 ，NL 被 驱动 表 必 须 走 索引 。 但 是 Id-10 
并 没有 走 索 引 。Id=2 估算 返回 905 行 数据 ， 一 般 情况 下 Rows 会 算 少 ， 这 里 就 暂且 认为 Id=2 
返回 905 行 数据 ， 那 么 Id=8 会 被 扫描 905 次 ， 也 就 是 说 DW_BO_ORDER 这 个 200 万 行 大 表 
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会 被 扫描 905 次 ， 而 且 每 次 都 是 全 表 扫 描 ， 这 就 是 为 什么 SQL 会 执行 5 个 多 小 时 。 

找到 SQL 的 性 能 瓶颈 之 后 ， 我 们 就 可 以 想 办 法 优化 SQL。 本 案例 有 两 种 优化 思路 ， 其 一 
是 让 大 表 只 被 扫描 一 次 , 其 二 是 不 减少 扫描 次 数 , 但 是 减少 大 表 每 次 被 扫描 的 体积 。 最 优 的 解 
决 方案 是 ， 想 办 法 让 Id=2 和 14=8 Ж HASH 连接 消除 Filter， 这 样 就 只 需要 扫描 1 KAK, A 
为 当时 数据 库 版 本 是 Oraclel0g, where 子 查 询 中 有 主 表 的 过 滤 条 件 ， 在 not exists 子 查 询 中 添 
加 HINT: HASH AJ 无 法 更 改 执行 计划 。 我 们 可 以 将 not exists 改写 为 “外 连接 + 子 表 连 接 列 
is null” 的 形式 , 让 其 走 HASH 连接 , 但 是 当时 没有 采用 这 种 改写 方式 。 因 为 大 表 要 被 扫描 905 
次 ， 每 次 都 是 全 表 扫 描 ， 如 果 能 减少 扫描 的 体积 ， 也 能 优化 SQL。 我 们 可 以 在 大 表 上 建立 一 
个 组 合 索 引 ， 这 样 就 能 避免 大 表 每 次 全 表 扫 描 ， 从 而 达到 减少 扫描 体积 的 目的 , 但 是 当时 朋友 
没 权限 建立 索引 。 最 终 选择 使 用 with as 子 句 优化 上 述 SQL. 


SQL> set timi on 
SQL» WITH D AS 
(SELECT Й materialize */ 
PARTY ID, 
BO ID, 
PROD ID, 
COMPLETE DT 
FROM РИ BO ORDER 
WHERE STAFF ID LIKE '36$' AND 
BO ACTION NAME ІМ (' 新 装 '， 


вњ тһ ppp p=, 
(o со —1 OY O1 4» Q) КЮ > O о со м! OY G > ш № 


UE, 
' 资 费 变更 ')) 
SELECT 

B.AREA_ID, 

A.PARTY ID, 

B.AREA NAME, 

C.NAME CHANNEL NAME, 

B.NAME PARTY NAME, 

B.ACCESS NUMBER, 

B.PROD SPEC, 
20 B.START DT, 
21 A.BO ACTION NAME, 
22 A.SO STAFF ID, 
23 A.ATOM ACTION ID, 
24 A.PROD ID 
25 FROM РИ CHANNEL с, 
26 DW CRM DAY USER B, 
21 DW BO ORDER A 
28 WHERE  A.PROD Ір = B.PROD ID AND 
29 A.CHANNEL ID - C.CHANNEL ID AND 
30 A.SO STAFF ID LIKE '36$' AND 
31 A.BO ACTION NAME IN (' 新 装 ', ' 移 机 ',' 资 费 变更 ') AND 
32 B.PROD SPEC ІМ (' 普 通电 话 '，'ADSL', 'LAN'，' 手 机 '， 
33 "ЕВ - 25', "Еб 移动 版 '/，'E9 版 1M( 老 版 ) '， 
34 "В EO, ' 普 通 新 版 8 ， 
35 "еш 紧密 融合 型 E9 套餐 产品 规格 '， 
36 ' (新 ) 全 省 紧密 融合 型 E9 套餐 产品 规格 '， 
37 HERRAZ ES £4, 
38 ' 新 春 欢 乐 送 之 E6 套餐 ') AND 
39 NOT EXISTS (SELECT * 
40 FROM D 
41 WHERE A.PARTY ID = D.PARTY_ID AND 
42 A.BO_ID != D.BO_ID AND 
43 A.PROD_ID != D.PROD_ID AND 
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44 A.COMPLETE DT - INTERVAL '7' DAY < D.COMPLETE DT); 

已 选择 49 245 11. 

已 用 时 间 : 00:00: 12.37。 

执行 计划 如 下 。 
Plan hash value: 2591883460 

| Id [Operation IName |Rows |Bytes| Cost (%CPU) | 
| 0 ISELECT STATEMENT | 905| 121K| 62428 (2)1 
| 1 | TEMP TABLE TRANSFORMATION | | | | 
| 2 | LOAD AS SELECT |DW BO ORDER | | | 
| S PARTITION RANGE ALL | | 114К|3228К| 9127 (2)1 
І% 4 | TABLE ACCESS FULL |DW BO ORDER | 114К|3228К| 9127 (2)1 
|* 5 | FILTER | | | | | 
jp; 6 | HASH JOIN | 9051 121®Ю| 12616 (2)1 
М | HASH JOIN | 905|99550| 12448  (2)| 
l. 8 | PARTITION RANGE ALL | 1979| 108K| 9168 (2) | 
[#49 | TABLE ACCESS FULL |DW BO ORDER | 1979| 108К| 9168 (2) | 
| *10 -| TABLE ACCESS FULL |DW CRM DAY USER | 309K| 15М| 3277 (2)1 
ІІІ! TABLE ACCESS FULL |DW CHANNEL |48425|1276К| 168 (27! 
|*12 | FILTER | | | | | 
[SU VIEW | | 114K|6791K| 90. (37/1 
| 14 | TABLE ACCESS FULL |SYS TEMP OFD9D662E D625B872| 114K|3228K| 90 (37-1 


4 - filter(TO CHAR("STAFF ID") LIKE '36%') 
5 - filter( NOT EXISTS (SELECT /%% */ 0 FROM (SELECT /** CACHE TEMP TABLE ("T1") 
*/ "со" 
"STAFF Ір", "С1" "PARTY Ір", "С2" "ВО Ір", "СЗ" "PROD ID","C4" "COMPLETE D 


Т" FROM 

"SYS"."SYS TEMP 0Е090662Е 06258872" "Т1") "D" WHERE (:B1=' 新 装 ' OR :В2=' 
ЖАЛ) oR :В3=' 

资费 变更 ') AND TO CHAR("D"."STAFF ID") LIKE '36%' AND "D"."PARTY Ір"=:В4 
AND 

"D"."BO ID"«»:B5 AND "D"."PROD ID"«»:B6 AND "D"."COMPLETE DT"»:B7-INTER 
VAL'407 


00:00:00' DAY(2) TO SECOND(0))) 
6 - access("A"."CHANNEL ID"-"C"."CHANNEL ID") 
7 - access("A"."PROD ID"-"B"."PROD ID") 
9 - filter("A"."PROD ID" IS NOT NULL AND ("A"."BO ACTION NAME"-' šf Ж ' OR "A"."BO- 
ACTION NAME"-' 
移 机 ' OR "A"."BO ACTION NAME"= ' 资 费 变更 ') AND TO CHAR("A"."SO STAFF ID") 
LIKE '36%') 
10 - filter("B"."PROD ЅРЕС"=' (Ж) 全 省 _ 紧密 融合 型 E9 套餐 产品 规格 ' OR "B"."PROD SPEC"- 
'ADSL' OR 
"B"."PROD ЅРЕС"='Е6 移动 版 ' OR "B"."PROD SPEC"-'EB8 - 25" OR "В"."РВОр 


SPEC"-'E9 版 

1M( 老 版 ) OR "B"."PROD SPEC"-'LAN' OR "B"."PROD SPEC"-'iÉjÉ E9' OR "B". 
"PROD SPEC"-' 

普通 电话 ' OR "B"."PROD SPEC"=' 普 通 新 版 E8' OR "B"."PROD SPEC"-'$ 4 紧密 融合 
型 ро 套餐 

产品 规格 ' OR "B"."PROD SPEC"=' 手 机 ' OR "B"."PROD _SPEC"=' 新 春 欢 乐 送 之 кє 套餐 
' OR 


"B" ."PROD_SPEC"= :新春 欢乐 送 之 ES ЖҰЖ”) 
12 - filter (:B1=' 新 装 ' OR :62=' 移 机 ，OR :B3=' 资 费 变 更 ') 
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13 - filter(TO CHAR("D"."STAFF ID") LIKE '36$' AND "D". "PARTY Ір"=:В1 AND "D",."BO T 
D"<>:B2 AND 
"D"."PROD ID"<>:B3 AND "D"."COMPLETE рт">:В4-ІМТЕКУАІ'+07 00:00:00' DAY 
(2) TO 
SECOND (0) ) 


统计 信息 
2 recursive calls 
29 db block gets 
110506 consistent gets 
22 physical reads 
656 redo size 
2438096 bytes sent via SQL*Net to client 
449 bytes received via SQL*Net from client 
11 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
49245 rows processed 


使 用 with as 子 句 将 大 表 要 被 访问 的 字段 查询 出 来 ， 一 共 4 个 字段 ， 然 后 过 滤 掉 不 需要 的 
数据 ， 添 加 HINT:MATERIALIZE 将 with as 子 句 查询 结果 固化 为 临时 表 ， 这 样 就 达到 了 减少 
扫描 体积 的 目的 。 假设 200 万 行 的 大 表 DW_BO_ORDER 有 占用 2GB 存储 空间 , RE 40 个 字 
Ві, 通过 with as 子 名 改写 之 后 ， 只 需要 存储 4 个 字段 数据 ， 这 时 只 需 200MB 存储 空间 ， 而 且 
with as 子 句 中 还 有 过 滤 条 件 ， 又 可 以 过 滤 掉 一 部 分 数据 ， 这 时 with as 子 句 可 能 就 只 需要 几 十 
兆 存 储 空间 。 虽 然 被 扫描 的 次 数 没有 改变 ， 但 是 每 次 被 扫描 的 体积 大 大 减少 ， 这 样 就 解决 了 
SQL 查询 性 能 。 最 终 SQL 可 以 在 12 秒 左右 跑 完 ， 一 共 返 回 4.9 万 行 数据 。 


2013 年 ， 一 朋友 咨询 如 何 优化 下 面 树 形 查 询 。 


select rownum, adn, zdn, 'cable' 
from (select distinct connect by root(t.tdl a dn) adn, t.tdl z dn zdn 
from AGGR 1 t 
where t.tdl operation «» 2 
and exists (select 1 
from CABLE 1 a 
where a.tdl operation «» 2 
and a.tdl dn - t.tdl z dn) 
start with exists (select 1 
from RESOURCE FACING SERVICE1 1 b 
where b.tdl operation «» 2 
and t.tdl a dn = b.tdl dn) 
connect by nocycle prior t.tdl z dn - t.tdl a dn); 


执行 计划 如 下 。 


SOL» select * from table(DBMS XPLAN.DISPLAY); 
Plan hash value: 1439701716 
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| 0 |SELECT STATEMENT | 1311251 59M| 
| 1| COUNT | | 

| 2 | VIEW | |31125| 59M| 
| 30] HASH UNIQUE | 131125| 59M| 
|%-4 | FILTER | | | 

5931 CONNECT BY NO FILTERING WITH SW (UNIQUE) | | | 

P 7671 TABLE ACCESS FULL |AGGR 1 | 171K| 4353К| 
pese TABLE ACCESS FULL |RESOURCE FACING SERVICE1 1| 1| 18 | 
I* 8.1 TABLE ACCESS FULL |CABLE 1 | 1| 14 | 


4 - filter("T"."TDL ОРЕВАТІОМ"<>2 AND EXISTS (SELECT 0 FROM "CABLE 1" "A" WHERE " 
А". "трі DN"-:B1 
AND "А". "Ті ОРЕВАТІОМ"<>2)) 
5 - access("T"."TDL A DN"=PRIOR "T"."TDL 2 DN") 
filter( EXISTS (SELECT 0 FROM "RESOURCE FACING SERVICE1 1" "B" WHERE "B 
"."TDL DN"-:Bl 
AND "B"."TDL ОРЕВАТІОМ"<>2)) 
7 - filter("B"."TDL DN"-:Bl AND "B"."TDL ОРЕВАТІОМ"<>2) 
8 - filter("A"."TDL рм"=:В1 AND "A"."TDL ОРЕВАТІОМ"<>2) 


25 rows selected. 
阅读 过 本 章 Filter 优化 经 典 案例 的 读者 能 很 快 发 现 : 执行 计划 中 ，Id=4 是 Filter, 14-5 和 
14-8 是 Id=4 的 儿子 ， 这 说 明 Id=8 会 被 多 次 反复 扫描 ，Id=8 走 的 是 全 表 扫 描 ， 这 显然 不 对 。 
在 进行 SQL 优化 的 时 候 ,我 们 需要 特别 留意 执行 计划 中 的 谓词 过 滤 信 息 。 执 行 计 划 中 Id=7 
的 谓词 过 滤 中 有 绑 定 变量 :B1, 但 是 SQL 语句 中 并 没有 绑 定 变量 。 大 家 是 否 还 记得 5.5 节 讲 到 :Bl 
表示 传 值 。 如 果 SQL 语句 本 身 没 有 绑 定 变量 ， 但 是 执行 计划 中 谓词 过 滤 信息 又 有 绑 定 变 量 
(:B1，:B2，B3..)， 这 说 明 有 绑 定 变 量 这 步 需 要 传 值 。 典 型 的 需要 传 值 的 有 标量 子 查 询 、Filter 
以 及 树 形 查询 中 start with 子 查 询 。 当 执行 计划 中 某 个 步骤 需要 传 值 ， 这 个 步骤 就 会 被 扫描 多 
次 。 执 行 计划 中 ，Id=7 谓词 有 绑 定 变量 ， 这 说 明 14-7 与 1d-8 一 样 ， 要 被 多 次 扫描 。 男 外 请 注 
意 ， 执 行 计划 中 Id=4 也 有 绑 定 变 量 ， 但 是 Id=4 的 绑 定 变量 与 Id-8 是 成 对 出 现 ，Id=5 的 绑 定 
变量 与 Id=7 也 是 成 对 出 现 ， 对 于 成 对 出 现 的 绑 定 变量 情况 ， 关 注 有 表 对 应 的 Id 即 可 ， 这 里 有 
表 对 应 的 Id 就 是 7 和 8。 
通过 上 面 分 析 ， 我 们 知道 SQL 的 性 能 瓶颈 在 14-7 和 Id=8 这 两 步 。 对 于 树 形 查询 ， 很 难 
通过 SQL 改写 减少 start with 子 查询 中 表 被 多 次 扫描 ， 所 以 只 能 想 办 法 减少 表 被 扫描 的 体积 。 
我 们 可 以 创建 下 面 两 个 索引 来 优化 SQL. 
create index idx a on CABLE 1(tdl dn,tdl operation); 
create index idx b on RESOURCE FACING SERVICE1 l(tdl dn,tdl operation); 
本 案例 也 可 以 使 用 with as 子 名 改写， 然后 将 子 查询 生成 临时 表 来 进行 优化 ， 但 是 with as 
子 名 改写 优化 的 性 能 没有 创建 索引 优化 的 性 能 高 ， 因 为 走 索 引 可 以 进行 INDEX RANGE 
SCAN, 而 且 不 需要 回 表 ,而 with as 子 句 需要 对 临时 表 进 行 全 表 扫 描 。 本 案例 的 目的 是 让 大 家 
重视 执行 计划 中 的 谓词 信息 ! 
还 有 一 个 比较 经 典 的 案例 , 也 需要 关注 谓词 信息 才能 优化 SQL, 但 是 限于 SQL 实在 太 长 ， 
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我 们 无 法 在 书 中 体现 ， 有 兴趣 的 读者 可 以 查看 博客 : http:/blog.csdn.net/robinson1988/article/ 
details/7002545 。 





2012 年 ， 一 朋友 请 求 优化 下 面 SQL， 该 SQL 在 RAC 环境 中 执行 ， 时 快 时 慢 ， 最 快 时 1 
秒 ， 最 慢 是 3 秒 。SQL 语句 如 下 。 


SELECT /*+INDEX (TMS,IDX1 TB EVT DLV W)*/ 
TMS .MAIL NUM, 
TMS.DLV BUREAU ORG CODE AS DLVORGCODE, 
RO.ORG SNAME AS DLVORGNAME, 
TMS.DLV PSEG CODE AS DLVSECTIONCODE, 
TMS.DLV PSEG NAME AS DLVSECTIONNAME, 
TO CHAR(TMS.DLV DATE, 'YYYY-MM-DD HH24:MI:SS') AS RECTIME, 
TMS.DLV STAFF CODE AS HANDOVERUSERCODE, 
TU2.REALNAME AS HANDOVERUSERNAME, 
DECODE(TMS.DLV STS CODE, 'I', “ЖЕН, 'H', "ЖЗА", TMS.DLV STS CODE) AS DLV STS CODE, 
CASE 
WHEN TMS.MAIL NUM LIKE "ЕС%" THEN 
П 代 收 ' 
WHEN TMS.MAIL NUM LIKE 'EDS$CW' THEN 
"eu 
WHEN TMS.MAIL NUM LIKE 'FJ$' THEN 
' 代 收 ' 
WHEN TMS.MAIL NUM LIKE 'GC%' THEN 
' 代 收 ' 
ELSE 
' 3e fi 
END MAIL NUM TYPE 
FROM TB EVT DLV W TMS 
LEFT JOIN RES ORG RO ON TMS.DLV BUREAU ORG CODE = RO.ORG CODE 
LEFT JOIN TB USER TU2 ON TU2.DELVORGCODE = TMS.DLV BUREAU ORG CODE 
AND TU2.USERNAME = TMS.DLV STAFF CODE 
WHERE NOT EXISTS 
(SELECT /*-INDEX(TDW,IDXl TB MAIL SECTION STORE)*/ 
MAIL NUM 
FROM TB MAIL SECTION STORE TDW 
WHERE TDW.MAIL NUM = TMS.MAIL NUM 
AND TDW.DLVORGCODE = TMS.DLV BUREAU ORG CODE 
and TDW.DLVORGCODE = '35000133' 
AND TDW.RECTIME »- 
TO DATE('2012-11-01 00:00', 'YYYY-MM-DD HH24:MI:SS') 
AND TO DATE('2012-11-08 15:15", 'YYYY-MM-DD НН24:М1:55') >= 
TDW.RECTIME 
and rownum = 1) 
AND TMS.DLV BUREAU ORG CODE - '35000133' 
AND TMS.DLV DATE >= TO DATE('2012-11-01 00:00', 'YYYY-MM-DD HH24:MI:SS') 
AND TO DATE('2012-11-08 15:15', 'YYYY-MM-DD HH24:MI:SS') »- TMS.DLV DATE 
AND ('' IS NULL OR TMS.DLV STAFF CODE = '') 
AND ('' IS NULL OR TU2.REALNAME LIKE '%%') 
AND TMS.REC AVAIL FLAG = '1'; 


执行 计划 如 下 。 


| Plan hash value: 1159587453 
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一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 六 了 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 


| OISELECT STATEMENT | 
|* 1| FILTER | 
| 


| 
| 
| 2| NESTED LOOPS OUTER | 131113493| 
[* 31| HASH JOIN RIGHT OUTER | | 129|10191| 
1% 4| TABLE ACCESS BY INDEX ROWID |EMS USER | 6| 120] 
1% 51 INDEX RANGE SCAN |EMS USER NEW INX ORG | 7| 
|* 6| TABLE ACCESS BY GLOBAL INDEX ROWID |TB EVT DLV W | 129| 7611| 
|% 71 INDEX ВАМСЕ 5САМ |IDX1 ТВ EVT ру и | 586| 
|* 8| COUNT STOPKEY | | | | 
|* 9| FILTER | | | | 
520] PARTITION RANGE ITERATOR | | 1| 31| 
| *11| TABLE ACCESS BY LOCAL INDEX ROWID|TB MAIL SECTION STORE | X 31| 
|*12] INDEX RANGE SCAN |Ірх1 TB MAIL SECTION STORE| 1| 
КЕН TABLE ACCESS BY INDEX ROWID IRES_ORG | 1| 24| 
|*14] INDEX RANGE SCAN |IDX RES ORG | 1| 


1 - filter(TO DATE('2012-11-01 00:00','YYYY-MM-DD HH24:MI:SS')«-TO DATE('2012-11-08 
15:15','YYYY-MM-DD HH24:MI:SS')) 

3 - access("EU"."USERNAME"-"TMS"."DLV STAFF CODE" AND 
"EU"."DELVORGCODE"-"TMS"."DLV BUREAU ORG. CODE") 

4 - filter("EU"."POSTMANKIND"«»5) 

5 - access ("EU". "DELVORGCODE"-' 35000133") 

filter(("TMS"."DLV DATE">=TO DATE('2012-11-01 00:00','YYYY-MM-DD НН24:М1:55") 


о 
1 


"TMS"."REC_AVAIL_FLAG"='1' AND "TMS"."DLV DATE"«-TO DATE('2012-11-08 
15:15','YYYY-MM-DD НН24:М1:55"))) 
7 - access("TMS"."DLV BUREAU ORG CODE"-'35000133') filter( IS NULL) 
8 - filter(ROWNUM-1) 
9 - filter((TO DATE('2012-11-01 00:00','YYYY-MM-DD НН24:М1:55")<-ТО DATE('2012-11-08 

15:15','YYYY-MM-DD HH24:MI:SS') AND :В1='35000133')) 

11 - filter(("TDW"."RECTIME"2-TO DATE('2012-11-01 00:00','YYYY-MM-DD HH24:MI:SS') AND 
"TDW"."RECTIME"«-TO DATE('2012-11-08 15:15','YYYY-MM-DD НН24:МІ:55"))) 

12 - access("TDW"."DLVORGCODE"-:B1 AND "TDW"."MAIL NUM"-:B2) 

14 - access("TMS"."DLV BUREAU ORG CODE"-"RO"."ORG CODE") 


首先 我 们 排除 执行 计划 中 14=8 到 Id=12 会 影响 SQL 性 能 的 可 能 性 ， 因 为 Id-8 到 Id=12 KIR 
回 1 行 (Id=8，COUNT STOPKEY，ROWNUM=1) 数据 ， 返 回 1 行 数 据 不 可 能 产生 性 能 问题 。 
执行 计划 的 入 口 是 Id=$， 走 的 是 索引 范围 扫描 ， 过 滤 条 件 是 "EU"."DELVORGCODE'"='35000133，， 
14-4 是 Id-5 中 索引 范围 扫描 的 回 表 操作 , 在 回 表 的 时 候 还 进行 了 过 滤 "EU"."POSTMANKIND" 
<>5„ 如果 要 追求 完美 , 我 们 可 以 将 POSTMANKIND 列 放 到 Id=5 中 的 索引 中 , 创建 组 合 索引 。 
14-5 返回 的 数据 量 较 少 , 因此 排除 了 Id=5 和 Id=4 产生 性 能 问题 的 可 能 性 。 现在 我 们 将 目光 转 
移 到 Id=7 和 Id=6 上面 来 ,Id=7 走 的 是 索引 范围 扫描 ,过 滤 条 件 是 "TMS"."DLV_BUREAU_ORG_ 
CODE"='35000133', 14-6 是 Id=7 的 索引 回 表 操作 ， 注 意 Id-6, Operation 中 出 现 了 GLOBAL 
关键 字 ， 这 说 明 TB_EVT_DLV_W 是 一 个 分 区 表 ， 而 且 Id=7 中 的 索引 是 全 局 索引 。Id=6 中 出 
现 了 时 间 过 滤 ， 一 般 的 分 区 表 都 是 根据 时 间 字 段 进 行 分 区 的 。 于 是 我 们 询问 朋友 TB ЕУТ. 
DLV W 是 不 是 根据 DLV DATE 进行 分 区 的 ， 朋 友 回 答 是 。 得 到 朋友 的 肯定 回答 ， 我 们 就 知 
道 该 SQL 的 性 能 问题 出 在 何 处 了 ， 问 题 出 在 14-7 和 Id-6 E. 


205 


我 们 应 该 将 Id=7 的 全 局 〈global) 索引 改 成 本 地 〈local) 索引 。 


| create index IDX2 TB EVT DLV W on TB EVT DLV W(DLV BUREAU ORG CODE) local; 


改 成 本 地 索引 之 后 ，Id=6 就 不 会 再 去 进行 时 间 过 滤 了 。 相 比 扫描 全 局 索引 ， 扫 描 本 地 索 
引 只 需要 到 对 应 的 索引 分 区 中 进行 扫描 ， 扫 描 的 叶子 块 数量 也 大 大 减少 。 建 立 本 地 索引 之 后 ， 
SQL 多 次 执行 都 能 稳定 在 1 秒 内 。 

如 果 过 滤 条 件 中 有 分 区 字段 ， 一 般 都 创建 本 地 索引 。 

如 果 过 滤 条 件 中 没有 分 区 字段 ， 一 般 都 创建 global 索引 ， 如 果 这 时 创建 成 local 索引 ， 会 
扫描 所 有 的 索引 分 区 ， 分 区 数量 越 多 ， 性 能 下 降 越 明显 。 假 设 有 1 000 个 分 区 ， 在 进行 索引 扫 
描 的 时 候 会 扫描 1 000 个 索引 分 区 , 此 时 相 比 global 索引 , 会 额外 多 读 取 至 少 1 000 个 索引 块 。 

假设 表 按 月 分 区 , 一 个 月 大 概 几 百 万 行 数据 , 但 是 只 查询 几 小 时 的 数据 , 数据 也 就 几 千 行 ， 
这 时 我 们 需要 将 分 区 列 包含 在 索引 中 ， 这 样 的 索引 就 是 有 前 缀 的 本 地 索引 。 假 设 表 按 月 分 区 ， 
但 是 查询 经 常 按 月 查询 或 者 跨 月 查询 , 这 时 我 们 就 不 需要 将 分 区 列 包含 在 索引 中 , 这 样 创建 的 
本 地 索引 就 是 非 前 级 的 本 地 索引 。 





9.14.1 案例 二 


2011 年 ， 一 税务 局 的 朋友 请 求 优 化 下 面 SQL。 


select * 
from (select t.zxid, 


t.fzjgdm, 
(select count(a.session id) 
from test v a 
where to char(t.zxid) = a.ZCRYZH) slzl, 
(select count(a.session id) 
from test v a 
where to ‚ char (t. zxid) = a.ZCRYZH 
and a.myd = '0') 无 评价 ， 
(select count(a.session id) 
from test v a 
where to char(t.zxid) = a.ZCRYZH 
and a.myd = '1') 满意 
(select count(a.session id) 
from test v a 
where to char(t.zxid) = a.ZCRYZH 
and a.myd = '2') 较 ; 
(select count(a.session id) 
from test v a 
where to Dobson zara) = a.ZCRYZH 
and a.myd = '3') — 
(select count(a.session | ia) 
from test v a 
where to char(t.zxid) = a.ZCRYZH 
and a.myd = '4') 较 不 满意 , 
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(select count(a.session id) 
from test v a 
where to char(t.zxid) = a.ZCRYZH 
and a.myd = "5") 不 满意 
from CC ZXJBXX t 
WHERE t.yxbz = 'Y') 
where slzl «» 0; 


该 SQL 有 7 个 标量 子 查询 ， 在 5.5 WPHI, xdi T PHYS da k ЙН, REOR IS 
数据 很 多 并 且 主 表 连 接 列 基数 很 高 ， 会 导致 子 查 询 被 多 次 扫描 。 该 SQL 竟然 有 7 个 标量 子 查 
询 ， 而 且 每 个 标量 子 查 询 除了 过 滤 条 件 不 一 样 ， 其 他 都 一 样 ， 显 然 我 们 可 以 将 标量 子 查 询 等 价 
改写 为 外 连接 ， 从 而 优化 SQL， 等 价 改写 之 后 的 写法 如 下 。 


SELECT T.ZXID, 


T.GH, 

T.XM, 

T.BM, 

T.FZJGDM, 

SUM(1) SLZL, 

SUM(DECODE(A.MYD, '0', 1, 0)) 无 评价 ， 
SUM(DECODE(A.MYD, '1', 1, 0)) 满意 ， 
SUM(DECODE(A.MYD, '2', 1, 0)) 较 满 意 ， 
SUM(DECODE(A.MYD, '3', 1, 0)) 一 般 ， 
SUM(DECODE(A.MYD, "4", 1, 0)) 较 不 满意 ， 
SUM(DECODE(A.MYD, "5", 1, 0)) 不 满意 


FROM CC ZXJBXX T, test v A 
where A.ZCRYZH - T.ZXID 
and T.YXBZ = ry" 
GROUP BY T.ZXID, T.GH, T.XM, T.BM, T.FZJGDM; 


SQL 改写 之 后 ， 因 为 两 表 只 有 关联 条 件 ， 没 有 过 滤 条 件 ， 所 以 两 表 关联 走 HASH 连接 ， 
test v 也 只 需要 被 扫描 一 次 ， 从 而 大 大 提升 SQL ЕВЕ 

ER SQL 其 实 是 一 个 典型 的 报表 开发 初学 者 在 刚 开始 工作 的 时 候 编 写 的 ， 强 烈 建 议 大 家 
要 加 强 SQL 编程 技能 。 


9.142 案例 二 
本 案例 发 生 在 2017 F, 是 一 个 比较 经 典 的 标量 子 查询 改写 优化 案例 .SQL 和 执行 计划 如 下 。 


SELECT A.LXR ID, 

A.SR, 
(SELECT C.JGID || 'G' || C.DLS BM || 'G' || C.DLS MC 

FROM KHGL DLSJBXX C, KHGL ZJKJ ZJKJ 

WHERE C.JGID - ZJKJ.JGID 
AND EXISTS (SELECT 1 
FROM LXR YH YH 
WHERE YH.KH ID = ZJKJ.KJ ID 






iXRITB)) AS ZJJGXX 
FROM LXR JBXX A 
WHERE A.STATUS = '1' 

AND A.GRDM = :v1 
AND EXISTS (SELECT 1 

FROM LXR YH YH, KHGL GRDLXX GRDL 

WHERE YH.FZGS DM = :v2 
AND YH.KHLX - '2' 
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AND YH.LXR_ID = A.LXR_ID 
AND GRDL.GRDL_ID = YH.KH_ID 
AND GRDL.STATUS = '1') 
AND ROWNUM < 21; 
Execution Plan 


Plan hash value: 704492369 


| Id | Operation | Name | Rows | Bytes | Cost (%СРО) | Time | 
| 0 | SELECT STATEMENT | | Tal 41 | 12 (0)| 00:00:01 | 
|* 1 | FATTER | | | | | 

|х 2 | НАЅН JOIN | | 28114 | 3761K| 156  (2)| 00:00:02 | 
|” XS TABLE ACCESS FULL | KHGL DLSJBXX | 15342 | 1063К| 89  (2)| 00:00:02 

| 4| TABLE ACCESS FULL | KHGL ZJKJ | 28114 | 1812К| 66 (0)| 00:00:01 | 
I* 5| INDEX RANGE SCAN | ХЕ YH ID IX | 21 68 | 4 (0)| 00:00:01 | 
|* 6 | COUNT STOPKEY | | | | | | 
| 7 | NESTED LOOPS SEMI | | 1. 41 | 12  (0)| 00:00:01 | 
|* В | TABLE ACCESS BY INDEX ROWID | IXR JBXX | 11] 39 | 5  (0)| 00:00:01 | 
|ж 9. INDEX RANGE SCAN | IDX LXR JEXX GRIM | T | 3  (0)| 00:00:01 | 
| 10 | VIEW PUSHED PREDICATE | W 50 1 | L | 2: | 7  (0)| 00:00:01 | 
| BENI NESTED LOOPS | | 1 [9210.1 7 (0)| 00:00:01 

ІР 27) TABLE ACCESS BY INDEX ROWID| LXR ҮН | i 75: | 5 (0)| 00:00:01 
|% 13-1 INDEX RANGE SCAN | IDX KHGL LXRYH FZGSDM | ds] | 4 (0)| 00:00:01 | 
PS23234 | INDEX RANGE SCAN | IDX GRDLXX XZOH FZGS | 1| 35. | 2  (0)| 00:00:01 | 


Predicate Information (identified by operation id): 





- access ("C"."JGID"-"ZJKJ". "JGID") 


2 
5 - access("YH"."KH Ір"=:В1 AND "YH"."KHLX"-'2' AND "YH","LXR ID'-:B2) 
6 - filter (ROWNUM<21) 
8 = filter ("А". STATUS"W=11") 
9 - access ("A"."GRDM"-:V1) 
13 = access("YH"."FZGS DM"-:V2 AND "YH"."LXR ID"-"A"."LXR ID" AND "YH"."KHLX"-'2") 
14 - access ("GRDL". "GRDL_ ID"z"YH"."KH ID" AND "GRDL"."STATUS"-']' ) 
filter("GRDL". "STATUS"-'1" ) 
Statistics 


l recursive calls 
2 db block gets 
103172 consistent gets 
21144 physical reads 
0 redo size 
533 bytes sent via SQL*Net to client 
472 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
1 3/8 protessde 


该 SQL 只 返回 1 行 数据 ， 但 是 逻辑 读 为 103 172， 显 然 SQL 还 能 进一步 优化 。 从 执行 计 
划 中 可 以 看 到 ，Id=1 是 Filter, Filter 下 面 有 两 个 儿子 ， 这 属于 有 害 的 Filter。Id=3 和 Id=4 的 两 
个 表 走 的 是 全 表 扫 描 ， 并 且 这 两 个 表 Id 前 面 没 有 *， 也 就 是 说 这 两 个 表 没 有 过 滤 条 件 。SQL 的 
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逻辑 读 绝 大 部 分 应 该 是 由 14-1 的 Filter 以 及 14-3 和 Id=4 这 两 个 表 贡 献 而 来 的 。 

14-3 和 Id=4 这 两 个 表 来 自 于 标量 子 查 询 。 注 意 观察 原始 SQL, 在 标量 子 查询 中 ，Id=3 与 
Id=4 iai 与 主 表 LXR JBXX 没有 直接 关联 ， 主 表 是 与 标量 子 查询 中 的 半 连 接 进行 关联 的 
(YH.LXR I XR ID). 

TIENES ірке) жен f Жш DUCES RI, 主 表 通 过 连接 列传 值 给 子 查 
询 。 因 为 本 案例 SQL 比较 特殊 ， 主 表 是 与 标量 子 查询 中 的 半 连 接 的 表 进 行 关 联 的 ， 主 表 没 有 
直接 与 标量 子 查 询 中 From 后 面 的 表 进行 关联 ， 这 就 导致 了 标量 子 查 询 中 From 后 面 的 表 没 能 
通过 连接 列 进行 传 值 , 从 而 导致 Id=3 和 Id=4 的 表 走 了 全 表 扫 描 , 也 导致 了 SQL 使 用 了 Filter, 
进而 使 整个 SQL 运行 缓慢 。 

为 了 消除 Filter， 同 时 也 为 了 能 使 Id-3 和 Id=4 的 两 个 表 能 走 索 引 ， 需 要 对 SQL 进行 等 价 
改写 , 将 标量 子 查 询 中 的 半 连 接 改写 为 内 连接 就 能 使 1d=3 和 Id=4 的 两 个 表 使 用 索引 了 。 在 标 
量子 查询 章节 中 提 到 过 ,标量 子 查 询 可 以 等 价 改写 为 外 连接 ,因为 标量 子 查询 中 没有 聚合 函数 ， 
因此 判断 Id=3 与 Id=4 两 表 关 联 之 后 应 该 是 返回 1 的 关系 ， 因 为 如 果 两 表 关 联 后 返回 n 的 关 
Z, SOL 会 报错 。 那 么 现在 只 需要 考虑 将 标量 子 查询 的 半 连 接 等 价 改写 为 内 连接 即 可 。 因 为 
原始 的 SQL 写 的 是 半 连 接 ， 没 有 写成 内 连接 ， 因 此 我 们 判断 标量 子 查 询 中 的 半 连 接应 该 是 属 
于 n 的 关系 , 将 半 连 接 改写 为 内 连接 , 如 果 半 连接 属于 nn 的 关系 , 要 先 将 半 连 接 变 成 1 的 关系 。 
所 以 原始 SQL 可 以 等 价 改写 为 下 面 SQL: 


SELECT A.LXR ID, A.SR, B.MSG AS ZJJGXX 
FROM LXR JBXX A, 
(SELECT C.JGID || '@" || C.DLS BM || 'G' || C.DLS MC AS MSG, 
YH.LXR ID 
FROM KHGL DLSJBXX C, 
KHGL | ZIKI ZJKJ, 
ТЕН ІҢ: 








BY LXR ID, KH ID) үн -- 对 连接 列 分 组 将 n 的 关系 变 为 1 的 关系 
WHERE C.JGID = ZJKJ.JGID ` 
AND YH.KH ID = ZJKJ.KJ ID) B 
WHERE A.LXR ID = B.LXR ID(*) 
AND A.STATUS = '1' 
AND A.GRDM = :у1 
AND EXISTS (SELECT 1 
FROM LXR YH YH, KHGL GRDLXX GRDL 
WHERE YH.FZGS DM = :v2 
AND YH.KHLX - '2' 
AND YH.LXR ID = A.LXR ID 
AND GRDL.GRDL ID = YH.KH ID 
AND GRDL.STATUS = '1') 
AND ROWNUM « 21; 


改写 之 后 ，SQL 的 执行 计划 如 下 : 
SQL» / 
Elapsed: 00:00:00.01 


Execution Plan 





Е км д, 


Plan hash value: 2638330795 








| Id | Operation | Name | Rows | Bytes | Cost (%CPU)| Time 

| O | SELECT STATEMENT | | 1| 1241 87 (3) 00:00:02 | 
|* 1 | COUNT STOFKEY | | | | | | 

| 2| NESTED LOOPS OUTER | | 1| 124| 87 (3)| 00:00:02 
| 3| NESTED IOOPS SEMI | | Li 411 12 (0| 00:00:01 | 
I* 41 TABLE ACCESS BY INDEX ROWID | IXR JEXX | 24 |53611 5 (0)1 00:00:01 | 
I* 5| INDEX RANGE SCAN | IDKIXR JEXX GRIM | 1 | 3  (0)| 00:00:01 
| 6| VIEW PUSHED PREDICATE | W 501 | i 29) 7 (0) 1 00:00:01 | 
to mud NESTED LOOPS | | Yl 1101 7  (0)| 00:00:01 | 
67581 TABLE ACCESS BY INDEX ROWID | IXR ҮН | 1 75 | 5 (0)| 00:00:01 
|* 9] INDEX RANGE 5САМ | IDK KHGL IXRYH FZGSIM | 1 | 4 (031 00:00:01 
|+ 10 | INDEX RANGE SCAN | IDX GRDIXX XZOH FZGS | 1 35 | 2  (0)| 00:00:01 | 
| 11 | VIEW PUSHED PREDICATE | | 1| 83| 75 (3)| 00:00:01 | 
| 12 NESTED LOOPS | | | | | | 

| 131 NESTED LOOPS | | 11 203| 75 (3)| 00:00:01 
1% 24 | HASH JOIN | | 1| 132| 74 (3) 00:00:01 | 
жес VIEW | | 1|  66| 7 (15)1 00:00:01 | 
| 161 SORT GROUP BY | | 1| 61 7 (5)! 00:00:01 | 
|+ 17 | TABLE ACCESS BY INDEX ROWID| LXR ҮН | 1| 68| 6 (01 00:00:01 | 
|* 18 | INDEX RANGE SCAN | IDX KHGL IXRYH IXRID | 14) | 4  (0)| 00:00:01 | 
| 19 | TABLE ACCESS FULL | KHGL ZJKJ | 28114 | 1812K| 66 (0)| 00:00:01 | 
|* 20 | INDEX UNIQUE SCAN | KHGL DLSJBXX PK | 11 | O (0)1 00:00:01 | 
|» 2-11 TABLE ACCESS BY INDEX ROWID | KHGL DLSJEXX | а ат] 1  (0)| 00:00:01 | 





1 - filter (ROWNUM«21) 
4 = filter("A"."STATUS"z'1') 
5 — access("A"."GRDM"-:V1) 
9 - access("YH"."FZGS DM"-:V2 AND "YH"."LXR ID"-"A"."LXR ID"-AND "YH".,"KHLX"-'2') 
0 - access("GRDL". "GRDE TO STYR” "ЕН: ID" AND "GRDL". "STATUS"='1' ) 
filter ("GRDL". "5ТАТО5"='1') 
14 — access("YH"."KH ID"-"ZJKJ"."KJ ID") 
17 - filter("KHLX"-'2') 
18 - access("LXR ID"-"A","LXR ID") 
20 - access("C". "JGID"-"ZJKJ". "JGID") 


Statistics 
0 recursive calls 
1 db block gets 
400 consistent gets 
0 physical reads 
0 redo size 
533 bytes sent via SQL*Net to client 
472 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
1 sorts (memory) 
0 sorts (disk) 
1 rows processed 


对 SQL 进行 等 价 改写 之 后 ，SQL 的 逻辑 读 下 降 到 400， 本 次 优化 也 就 到 此 为 止 。 
通过 本 案例 ， 各 位 读者 应 该 对 SQL 等 价 改写 引起 足够 重视 ， 同 时 也 要 掌握 标量 子 查询 等 
价 改写 为 外 连接 ， 半 连接 等 价 改写 为 内 连接 ， 反 连接 改写 为 外 连接 等 最 基本 的 SQL 改写 技巧 ， 
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男 外 ， 大 家 还 要 对 表 与 表 之 间 关 系 引 起 足够 重视 。 


本 案例 发 生 在 2011 年 ， 当 时 作者 罗 老 师 在 惠普 担任 开发 DBA, 支撑 宝洁 公司 的 数据 仓库 项 
目 。 为 了 避免 泄露 信息 ， 他 对 SQL 语句 做 了 适当 修改 。ETL 开发 人 员 发 来 邮件 问 能 不 能 想 办 法 
提升 一 下 下 面 UPDATE 语句 性 能 ， 该 UPDATE 执行 了 30 分 钟 还 没 执行 完毕 ，SQL 语句 如 下 。 


| UPDATE OPT ACCT FDIM A 









SET ACCT SKID - (SELECT ACCT SKID 
FROM OPT ACCT FDIM BKP B 
WHERE A.ACCT ID - B.ACCT ID); 


ОРТ ACCT FDIM 有 226474 1711, ОРТ ACCT ЕРІМ ВКР 有 227817 行 数据 。 
UPDATE 后 面 跟 子 查询 类 似 嵌 套 循环 ， 它 的 算法 与 标量 子 查 询 ，Filter 一 模 一 样 。 也 就 是 说 
ОРТ ACCT ЕРІМ 表 相 当 于 岗 套 循环 的 驱动 表 ，OPT_ACCT_ ЕРІМ ВКР ЖІК ЖЕ ЖИ 
被 驱动 表 , 那么 这 里 表 OPT_ACCT ЕРІМ _BKP 就 会 被 扫描 20 多 万 次 .OPT_ АССТ ЕРІМ ВКР 
是 通过 CTAS 创建 的 备份 表 ， 用 来 备份 OPT_ACCT ЕРІМ 表 的 数据 。 骨 套 循环 被 驱动 表 应 该 
走 索 引 , 但 是 OPT_ACCT ЕРІМ ВКР 是 通过 CTAS 创建 的 ， 仅 仅 用 于 备份 ， 该 表 上 面 没有 任 
何 索引 ， 这 就 是 说 ОРТ ACCT FDIM ВКР 要 被 扫描 20 多 万 次 ， 而 且 每 次 都 是 全 表 扫 描 ， 这 
就 是 为 什么 UPDATE 执行 了 30 分 钟 还 没 执行 完毕 。 我 们 可 以 创建 一 个 索引 (ACCT ID, 
ACCT SKID) 从 而 避免 ОРТ ACCT FDIM ВКР 每 次 被 全 表 扫 描 ， 虽 然 这 种 方法 能 优化 该 
SQL， 但 是 此 时 索引 会 被 扫描 20 多 万 次 。 如 果 要 更 新 的 表 有 几 千 万 行 甚至 上 亿 行 数据 ， 显 然 
不 能 通过 创建 索引 的 方法 来 优化 SQL。 考 虑 到 ETL 开发 人 员 后 续 还 有 类 似 需求 ， 笔 者 决定 采 
用 存储 过 程 并 且 利 用 ROWID 对 关联 更 新 进行 优化 。 存 储 过 程 代码 如 下 。 


SQL» DECLARE 

2 CURSOR CUR B IS 

3 SELECT 

4 B.ACCT ID, B.ACCT SKID, A.ROWID ROW ID 

5 FROM OPT ACCT DIM A, OPT ACCT DIM BKP B 
6 WHERE A.ACCT ID - B.ACCT ID 
1 ORDER BY A.ROWID; 
8 V COUNTER NUMBER; 


9 BEGIN 
10 У COUNTER := 0; 
11 FOR ROW B IN CUR B LOOP 
12 UPDATE OPT ACCT DIM 
13 SET ACCT SKID - ROW B.ACCT SKID 
14 WHERE ROWID — ROW B.ROW ID; 
15 V COUNTER :- V COUNTER + 1; 
16 IF (V COUNTER »- 1000) THEN 
17 COMMIT; 
18 V_COUNTER := 0; 
19 END IF; 
20 END LOOP; 
21 COMMIT; 
22 END; 
23 / 
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第 9 章 SQL 优化 案例 赏析 
PL/SQL procedure successfully completed. 


Elapsed: 00:01:21.58 


将 关联 更 新 改写 成 存储 过 程 ， 利 用 КОМІР 进行 更 新 只 需要 1 分 22 秒 就 可 执行 完毕 。 当 
时 并 没有 采用 批量 游标 方式 进行 更 新 ， 如 果 采 用 批量 游标 ， 速 度 更 快 。 以 下 是 批量 游标 的 


PLSQL 代码 。 
declare 
maxrows number default 100000; 
rowid table dbms sql.urowid table; 


acct skid table dbms sql.Number Table; 
cursor cur update is 
SELECT B.ACCT SKID, A.ROWID ROW ID 
FROM OPT ACCT DIM A, OPT ACCT DIM BKP B 
WHERE A.ACCT ID = B.ACCT ID 
ORDER BY A.ROWID; 
begin 
open cur update; 
loop 
EXIT WHEN cur update$NOTFOUND; 
FETCH cur update bulk collect 
into acct skid table, rowid table limit maxrows; 
forall i in 1 .. rowid table.count 
update OPT ACCT DIM 
set acct skid = acct skid table (і) 
where rowid = rowid table(i); 
commit; 
end loop; 
close cur update; 
end; 


/ 

细心 的 读者 会 发 现 ,在 游标 定义 中 ， 我 们 对 要 更 新 的 表 根据 КОМІР 进行 了 排序 操作 ， 这 
是 为 什么 呢 ? 同一 个 块 中 ROWID 是 连续 的 ， 物 理 上 连续 的 块 组 成 了 区 ， 那 么 同一 个 区 里 面 
ROWID 也 是 连续 的 。 对 ROWID 进行 排序 是 为 了 保证 在 更 新 表 的 时 候 ， 被 更 新 的 块 尽量 不 被 
ІҢ buffer cache， 从 而 减少 物理 IO。 假设 要 被 更 新 的 表 有 20GB， 数 据 库 的 buffer cache 只 
有 10GB， 这 时 buffer cache 不 能 完全 容纳 要 被 更 新 的 表 ， 有 部 分 块 会 被 挤 压 出 buffer cache. 
这 时 如 果 不 对 КОМІР 进行 排序 ， 被 更 新 的 块 有 可 能 会 被 反复 读 入 buffer cache， 然 后 挤 压 出 
buffer cache， 然 后 重复 读 入 、 挤 压 ， 此 时 会 引发 大 量 的 IO 读 写 操作 。 假 设 一 个 块 存储 200 fT 
数据 ， 最 极端 的 情况 就 是 每 个 块 要 被 读 入 / 写 出 到 磁盘 200 次 ， 这 样 读 取 的 表 就 不 是 20GB， 而 
是 〈200X20) GB。 如 果 对 КОМІР 进行 排序 ， 这 样 就 能 保证 一 个 块 只 需 被 读 入 buffer cache 
一 次 ， 这 样 就 避免 了 大 量 的 IO 读 写 操作 。 有 读者 会 问 ， 排 序 不 也 耗费 资源 吗 ? 这 时 排序 耗费 
的 资源 远 远 低 于 数据 块 被 反复 挤 压 出 buffer cache 所 耗费 的 开销 。 如 果 要 被 更 新 的 表 很 小 ， 
buffer cache 能 完全 容纳 下 要 被 更 新 的 表 , 这 时 就 不 要 对 ROWID 进行 排序 了 , 因为 buffer cache 
很 大 ， 块 不 会 被 挤 压 出 buffer cache， 此 时 对 ROWID 排序 反而 会 影响 性 能 。 大 家 以 后 遇 到 类 
似 需求 , 要 先 比较 被 更 新 的 表 与 buffer cache K/h, 同时 也 要 考虑 数据 库 繁 忙 程度 、buffer cache 
还 剩余 多 少 空闲 块 等 一 系列 因素 。 

下 面 实验 验证 如 果 不 对 ROWID 排序 ， 块 有 可 能 被 反复 扫描 的 观点 。 


9.16 ”外 连接 有 OR 关联 条 件 只 能 走 NL 


我 们 先 创建 两 个 表 , 分 别 取 名 为 a，b， 为 了 模拟 实际 情况 ,将 a, b 中 数据 随机 打 乱 存储 。 


create table a as select * from dba objects order by dbms random.value; 


create table b as select * from dba objects order by dbms random.value; 


查看 返回 结果 如 下 。 


SQL» select owner,rid as "ROWID",block# 
from (SELECT B.owner, 

3 A.ROWID rid, 

4 dbms_rowid.rowid block_number (A.rowid) block# 
5 FROM A, B 
6 
7 


м 


WHERE A.object_id = B.object id) 
where rownum <= 10; 


OWNER ROWID BLOCK# 
PUBLIC AAAS+CAAEAACEPdAAs 541661 
PUBLIC AAAS+CAAEAACEp2AAP 543350 
sys AAAS+CAAEAACEgFAAJ 542725 
SYS АААЅ+СААЕААСЕЦ9ААс 543677 
MDSYS AAAS+CAAEAACEknAAi 543015 
SYS AAAS+CAAEAACEutAA9 543661 
SYS АААЅ+СААЕААСЕҺКАА4 542801 
SYSMAN AAAS+CAAEAACEvzAAC 543731 
PUBLIC AAAS+CAAEAACE1BAA3 543041 
PUBLIC AAAS+CAAEAACEwUAAy 543764 


从 SQL 碍 询 结果 中 我 们 可 以 看 到 ， 返 回 的 数据 是 无 序 的 。 如 果 关联 的 两 个 表 连 接 列 本 身 
是 有 序 递增 的 ， 比 如 序列 值 、 时 间 ， 这 时 两 表 关 联 返 回 的 结果 是 部 分 有 序 的 ， 可 以 不 用 排序 ， 
在 实际 工作 中 ， 要 具体 情况 具体 分 析 。 

本 案例 也 可 以 采用 MERGE INTO 对 UPDATE 子 查 询 进行 等 价 改写 。 


merge into OPT ACCT FDIM A 
using OPT ACCT FDIM BKP B 
on (A.ACCT ID = B.ACCT ID) 
when mached then update set a.ACCT SKID - B.ACCT SKID; 


MERGE INTO n] А НАЕ RETARA E HASH 连接 ， 而 且 MERGE INTO 可 以 开 
启 并 行 DML、 并 行 查询 ， 而 采用 PLSQL 更 新 不 能 开启 并 行 ， 所 以 MERGE INTO 在 速度 上 有 
优势 。PLSQL 更 新 可 以 批量 提交 ， 对 UNDO 占用 小 ， 而 MERGE INTO 要 等 提交 的 时 候 才 会 
释放 UNDO. RH PLSQL 更 新 不 需要 担心 进程 突然 断 开 连接 ，MERGE INTO 更 新 如 果 进 程 
断 开 连接 会 导致 UNDO 很 难 释放 。 所 以 ， 如 果 追 求 更 新 速度 且 被 更 新 的 表 并 发 量 很 小 ， 可 以 
考虑 采用 MERGE INTO， 如 果 追 求 安全 、 平 稳 ， 可 以 采用 PLSQL 更 新 。 


下 面 SQL 有 OR 关联 条 件 。 


| SELECT A.CONTRACT ID, B.BORROWER ID 






FROM blfct.bl rtl con overdue fact A 
LEFT JOIN BLpub.Bl Contract Dim B ON A.DEALER ID - B.DEALER ID 
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OR A.OVERDUE DD = B.Overdue Dd 
WHERE A.ETL DATE BETWEEN DATE '2016-12-19' AND DATE '2016-12-20'; 


执行 计划 如 下 。 
Plan hash value: 121649910 


| Та | Operation | Name | Вояв | Bytes | Cost ($CPU)| 
| 0 | SELECT STATEMENT | | 163M| 5469M| 4421М (1)| 
| 1 | NESTED LOOPS OUTER | | 163M| 5469М| 4421М (1)| 
{Ж Ж] TABLE ACCESS FULL | BL RTL CON OVERDUE FACT | 1815! 3898К| 2192K (2)! 
| 3 | VIEW | | 903 | 11739 | 24354 (1) | 
]* 4 ] TABLE ACCESS FULL| BL CONTRACT DIM | 903 | 12642 | 24354 (1) 


Predicate Information (identified by operation id): 


2 -一 filter("A"."ETL DATE"2-TO DATE(' 2016-12-19 00:00:00', 'syyyy-mm-dd 
hh24:mi:ss') AND "A"."ETL DATE"«-TO DATE(' 2016-12-20 00:00:00', 'syy 
yy-mm-dd 
hh24:mi:ss')) 
4 — filter("A"."OVERDUE DD"-"B"."OVERDUE DD" OR "A"."DEALER ID"-"B"."DEALER ID") 


从 执行 计划 中 看 到 ， 两 表 走 的 是 嵌 套 循环 。 当 两 表 用 外 连接 进行 关联 ， 关 联系 件 中 有 OR 
关联 条 件 ， 那 么 这 时 只 能 走 嵌 套 循 环 ， 而 且 驱 动 表 固 定 为 主 表 ， 此 时 不 能 走 HASH 连接 ， 即 
使 通过 HINT: USE HASH 也 无 法 修改 执行 计划 。 如 果 主 表 数 据 量 很 大 ， 那么 这 时 就 会 出 现 严 
重 性 能 问题 。 我 们 可 以 将 外 连接 的 OR 关联 /过 滤 条 件 放 到 查询 中 ， 用 case when 进行 过 滤 ， 从 
而 让 SQL 可 以 走 HASH 连接 。 


EXPLAIN PLAN FOR 

SELECT A.CONTRACT ID, 
case 

when A.DEALER_ID = B.DEALER ID OR A.OVERDUE DD = B.Overdue Dd then 
B.BORROWER ID 
end 
FROM blfct.bl rtl con overdue fact A 
LEFT JOIN BLpub.Bl Contract Dim B ON A.DEALER ID = B.DEALER ID 
WHERE A.ETL DATE BETWEEN DATE '2016-12-19' AND DATE '2016-12-20'; 


执行 计划 如 下 。 
select * from table(dbms xplan.display()); 


Plan hash value: 3927476067 


| Id [Operation | Name |Rows | Bytes |TempSpc|Cost (%СРО) | 
| 0 |SELECT STATEMENT | | 57M| 1965М| | 2218К! (9, 
|% 1 | HASH JOIN OUTER | | S7MI 1965М| 6032К| 2218K (2) | 
|% 2 | TABLE ACCESS FULL| BL RTL СОМ OVERDUE FACT | 181K|  3898K| | 2192K (2)| 
| 3 | TABLE ACCESS'FULL| BL CONTRACT DIM | 640K| 8763К| |24349 (1) | 


Predicate Information (identified by operation id): 


916 ”外 连接 有 OR 关联 条 件 只 能 走 NL 


1 - access("A"."DEALER ID"-"B"."DEALER ID" (+) ) 
2 - filter("A"."ETL DATE">=TO DATE(' 2016-12-19 00:00:00", 'syyyy-mm-dd hh24:mi: 
вв") AND 
"A"."ETL БАТЕ"<-ТО DATE(' 2016-12-20 00:00:00", 'syyyy-mm-dd hh24:mi: 


85')) 
利用 case when 改写 外 连接 OR 连接 条 件 有 个 限制 ， 从 表 只 能 是 1 的 关系 ， 不 能 是 n 的 关 
系 ， 从 表 要 展示 多 少 个 列 ， 就 要 写 多 少 个 case when。 我们 利用 EMP 与 DEPT 进行 讲解 。EMP 
与 DEPT Æ n: 1 关系 ， 现 有 如 下 SQL. 


select e.*, d.deptno deptno2, d.loc 
from scott.emp e 
left join scott.dept d on d.deptno = e.deptno 
and (d.deptno >= e.sal and e.sal < 1000 or 
e.ename like '%O%'); 


执行 计划 如 下 。 


Plan hash value: 2962868874 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU) |Тіпе 

| 0 | SELECT STATEMENT | | 14 | 826 | 27 (0) |00:00:011| 
| 1 | NESTED LOOPS OUTER | | 14 | 826 | 17- (0)]|00:00:01] 
(М 72271 TABLE ACCESS FULL | EMP | 14 | 532; | 3 (0)100:00:011| 
18:3 | VIEW | | d 24 | 1 (0)|00:00:01| 
I» ap] TABLE ACCESS BY INDEX ROWID| DEPT | Т | 11 1 (0) 100:00:01| 
[* 159 INDEX UNIQUE 5САМ | PK DEPT | iini | 0 (0) 100:00:01]| 


4 - filter("E"."ENAME" IS NOT NULL AND "Е". "ЕМАМЕ" IS NOT NULL AND 
"E"."ENAME" LIKE '$0$' OR "D"."DEPTNO"»2-"E"."SAL" AND "E"."SAL"«1000) 
5 - access("D"."DEPTNO"-"E"."DEPTNO") 


执行 计划 中 两 表 关 联 走 的 是 舱 套 循环 ， 驱 动 表 是 主 表 EMP。 现 在 我 们 添加 HINT: 
USE_HASH 尝试 改变 表 连 接 方式 。 


SQL» select /*+ use hash(e,d) */ 
e.*, d.deptno deptno2, а.1ос 
from scott.emp e 
left join scott.dept d on d.deptno = e.deptno 
and (d.deptno »- e.sal and e.sal « 1000 or 
e.ename like '$0$'); 


Oy Cn mw 


14 rows selected. 


Execution Plan 


Plan hash value: 2962868874 


| Id | Operation | Name | Rows | Bytes | Cost (%CPU) |Time 
| 0 | SELECT STATEMENT | | 14 | 826 | 17 (0) 100:00:01| 
| 1 | NESTED LOOPS OUTER | | 14 | 826 | 17 (0) 100:00:01| 
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| “1 TABLE ACCESS FULL | EMP | 14 | 532 | 3 (0) 100:00:01| 
|7 530 VIEW s | | А; 5) eX | 1 (0)100:00:01| 
|%-4-) TABLE ACCESS BY INDEX ROWID| DEPT | 1ч] їл. “| 1 (0)|00:00:01| 
кю | INDEX UNIQUE SCAN | PK DEPT | 1 | | 0 (0)|00:00:01| 


4 - filter("E"."ENAME" IS NOT NULL AND "E"."ENAME" IS NOT NULL AND 
"E"."ENAME" LIKE '$0$' OR "D"."DEPTNO"»-"E"."SAL" AND "E"."SAL"«1000) 
5 — access("D"."DEPTNO"-"E", "DEPTNO") 


添加 HINT 无 法 更 改 执行 计划 。 因 为 SQL 语句 中 从 表 DEPT 属于 1 的 关系 ， 从 表 DEPT 
要 展示 两 个 列 ， 需 要 对 应 写 上 两 个 case when。 改 写 的 SQL 如 下 。 


select e.*, 
case 
when (d.deptno >= e.sal and e.sal < 1000 or e.ename like '%O%') then 
d.deptno 
end deptno2, 
case 
when (d.deptno >= e.sal and e.sal < 1000 or e.ename like '%O%') then 
d.loc 
end loc 
from scott.emp e 
left join scott.dept d on d.deptno = e.deptno; 


改写 后 的 执行 计划 如 下 。 


SQL> select е.*, 

2 case 

3 when (d.deptno >= e.sal and e.sal < 1000 or e.ename like '$0$') then 
4 d.deptno 

5 end deptno2, 

6 case 

1 when (d.deptno >= e.sal and e.sal < 1000 or e.ename like '$0$') then 
8 : d.loc 

9 end loc 

0 from scott.emp e 

1 left join scott.dept d on d.deptno - e.deptno; 


14 rows selected. 


Execution Plan 


Plan hash value: 3387915970 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time 

| 0 | SELECT 5ТАТЕМЕМТ | І 14 | 686 | 7 (15) | 00:00:01 | 
|% 1 | HASH JOIN OUTER | | 14 | 686 | 4. (45) [+005005 01 J 
| 2 | TABLE ACCESS FULL| EMP | 14 | 532 | 3 (9) 1 00:00:01 | 
| Sel TABLE ACCESS FULL| DEPT | 4 | 44 | 3 (0) 1 00:00:01 | 


Predicate Information (identified by operation id): 
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917 ЮИ СВО 


| L - access("D"."DEPTNO" (+) ="E" , "DEPTNO") 


用 case when 改写 之 后 ， 两 表 自 动 走 了 HASH 连接 。 
如 果 主 表 属 于 1 的 关系 ， 从 表 属 于 n 的 关系 ， 我 们 就 不 能 用 case when 进行 等 价 改写 ， 例 
子 如 下 。 


select d.*, e.deptno deptno2, e.ename, e.sal 
from dept d 
left join emp e on d.deptno = e.deptno 
and (d.deptno >= e.sal and е.за1 < 1000 or 
e.ename like '%0%'); 


SQL 中 DEPT Ж Ж, EMP 是 从 表 ，DEPT 5 EMP 是 1: n 的 关系 ， 此 时 不 能 将 SQL 改 
写 为 如 下 写法 。 


select d.*, 
case 
when (d.deptno >= e.sal and e.sal < 1000 or e.ename like '$0$') then 
e.deptno 
end deptno2, 
case 
when (d.deptno >= e.sal and e.sal < 1000 or e.ename like '$0$') then 
e.ename 
end ename, 
case 
when (d.deptno >= e.sal and e.sal < 1000 or e.ename like '$0$') then 
e.sal 
end sal 
from dept d 
left join emp e on d.deptno - e.deptno; 


我 们 可 以 将 SQL 改写 为 如 下 写法 。 


select b.*, a.deptno, a.ename, a.sal 
from dept b 
left join (select d.deptno, e.ename, e.sal 
from dept d, emp е 
where d.deptno = e.deptno 
and (d.deptno >= e.sal and e.sal < 1000 or 
e.ename like '%O%')) a on b.deptno = a.deptno; 


如 果 两 表 是 n n 关系 ， 这 时 就 无 法 对 SQL 进行 改写 了 ， 在 日 常 工 作 中 一 般 也 遇 不 到 n п 
关系 。 


2012 年 ， 一 位 女性 朋友 DBA 请 求 协助 优化 如 下 SQL. 


SELECT "А1"."СОрЕ", "AI"."DEVICE ID", "Al"."SIDEB PORT ID", "А1". "VERSION" 
FROM (SELECT 
"A2 " ч " CODE " "CODE " ? 
"A2"."DEVICE ID" "DEVICE ID", 
"A2"."SIDEB PORT ID" "SIDEB PORT ID", 
"A3"."VERSION" "VERSION", 
ROW NUMBER() OVER(PARTITION BY "A4"."PROD ID" ORDER BY "A4"."HIST TIME" DESC 






) "RN" 
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FROM "RM"."H PROD 2 RF SERV" "А4", 


"RM". "H | |. RSC FACING | SERV LINE ITEM" "A3", 
"RM" . "CONNECTOR" "A2" 


WHERE "A4"."SERV ID" = "A3",."SERV ID" 


AND "A3"."LINE ID" = "A2"."CONNECTOR ID" 
AND EXISTS (SELECT 0 


FROM "ВМ", "РЕУІСЕ ITEM" "А5" 


WHERE "А5"."ПЕУІСЕ ID" = "A2"."DEVICE ID" 


AND "А5"."ІТЕМ SPEC ID" = 200006 
AND "A5"."VALUE" ='7') 


AND "A4"."PROD ID" = 313) "А1" 
WHERE "A1"."RN" = 1; 


执行 计划 如 下 。 

| Id IOperation IName 

| 0 |SELECT STATEMENT | 

|* 1 | VIEW 

|* 2 | WINDOW SORT PUSHED RANK | 

(27371 NESTED LOOPS | 

ШЕЛ NESTED LOOPS | 

І 54 МІ IN AN | 

| 6 | SORT UNIQUE | 

|* 71 TABLE ACCESS BY INDEX ROWID|DEVICE ITEM 

p* 8 | INDEX RANGE SCAN |IDX DEVICE ITEM VALE 

| 8.1 BUFFER SORT | 

| 10 | TABLE ACCESS BY INDEX ROWID|H PROD 2 RF SERV 

[*л || INDEX ВАМСЕ SCAN |IDX | HP2RS | PRODID . SERVID 
1712.2] TABLE ACCESS BY INDEX ROWID |Н |! RSC | FACING | SERV : LINE ITEM 
1*18 | INDEX RANGE SCAN | IDX | HRFSLI SERV 

1*14 | TABLE ACCESS BY INDEX ROWID | CONNECTOR 

[919 1 INDEX UNIQUE SCAN | PK CONNECTOR 





1 =- filter("A1"."RN"-1) 
2 - filter(ROW NUMBER() OVER ( PARTITION BY "A4"."PROD ID" ORDER BY 


INTERNAL FUNCTION ("А4"."НІЅТ TIME") DESC )<=1) 


du filterz("A5". "ITEM SPEC ID"-200006) 

8 - access("A5"."VALUE"-'7') 

11 - access("A4"."PROD ID"-313) 
13 - access("A4"."SERV ID"-"A3"."SERV ID") 
14 т filter("AS"."DEVICE ID"-"A2","DEVICE ID") 
15 - access("A3"."LINE ID"-"A2","CONNECTOR ID") 


Statistics 
recursive calls 
db block gets 





physical reads 

redo size 

bytes sent via SQL*Net to client 

bytes received via SQL*Net from client 
SQL*Net roundtrips to/from client 
sorts (memory) 

sorts (disk) 





(10)| 
(10) | 
(10) | 
(6) 
(6) | 
(8) | 
(0) | 
(0) | 
(0) | 
(15) | 
(0) | 
(0) | 
(0) | 


9.17 ”把 你 脑袋 当 СВО 


该 SQL 要 执行 9.437 秒 , 只 返回 一 行 数据 ,其 中 A5 有 48 194 511 行 数 据 ,A2 有 35 467 304 
行 数 据 ， 其 余 表 都 是 小 表 。 

首先 ， 笔 者 运用 SQL 三 段 分 拆 方法 ， 检 查 SQL 写法 ， 经 过 检查 ，SQL 写法 没有 问题 。 

其 次 笔者 检查 执行 计划 。 执 行 计 划 中 Id=5 出 现 了 MERGE JOIN CARTESIAN， 这 一 般 都 
是 统计 信息 收集 不 准确 ， 将 离 MERGE JOIN CARTESIAN 关键 字 最 近 的 表 (Id=7)Rows 估算 为 
1 导致 。 

正常 情况 下 ， 应 该 先 检查 SQL 中 所 有 表 的 统计 信息 是 否 过 期 ， 如 果 统 计 信 息 过 期 了 应 该 
立即 收集 。 因 为 做 了 太 多 的 SQL 优化 ， 遇 到 SQL 出 现 了 性 能 问题 ， 已 经 形成 条 件 反 射 想 要 立 
刻 优化 它 ， 所 以 ， 当 时 没有 立即 对 表 收 集 统 计 信息 。 

如 果 想 要 从 执行 计划 入 手 优 化 SQL， 我 们 一 般 要 从 执行 计划 的 入 口 开 始 检 查 ， 检 查 Rows 
估算 是 否 准 确 。 当 然 了 ， 如 果 执 行 计划 中 有 明显 值得 怀疑 的 地 方 , 我 们 也 可 以 直接 检查 值得 怀 
疑 之 处 。 

执行 计划 的 入 口 是 Id-8, 14-8 是 索引 范围 扫描 ， 通 过 Id=7 回 表 。 于 是 让 朋友 运行 如 
Е 801. 


SELECT COUNT(*) 
FROM "RM"."DEVICE ITEM" "д5" 

WHERE "А5"."ІТЕМ SPEC ID" = 200006 
AND "A5"."VALUE" = '7'; 


得 到 反馈 ， 上 面 查 询 返 回 68384 行 数 据 。 其 次 ， 查 询 执行 计划 中 14-11 和 Id=10 应 该 返回 
多 少数 据 (A4)， 运 行 如 下 SQL. 
і select count(*) from Н PROD 2 RF SERV where prod іа = 313; 

得 到 反馈 ， 上 面 查询 返回 6 行 数 据 。 根 据 以 上 信息 我 们 知道 应 该 怎么 优化 上 述 SQL T. 
我 们 再 来 查看 原始 SQL 的 部 分 代码 。 


FROM "RM"."H PROD 2 RF SERV" "A4", 
"RM"."H RSC FACING SERV LINE ITEM" "A3", 
"ВМ". "CONNECTOR" "A2" 
WHERE "A4"."SERV ID" - "A3"."SERV ID" 
AND "A3"."LINE ID" - "A2"."CONNECTOR ID" 


AND EXISTS (SELECT 0 
FROM "RM"."DEVICE ITEM" "д5" 
WHERE "AS"."DEVICE ID" = "A2"."DEVICE ID" 
AND "AS"."ITEM SPEC ID" = 200006 
AND "А5". "ҮАШЈЕ" -'7') 
AND "A4"."PROD ID" - 313) 


AA 过 滤 后 只 返回 6 行 数据 ，A3 是 小 表 ，A2 有 35 467 304 行 数据 ，A5 过 滤 后 返回 6 万 行 
数据 ， 其 中 A3，A2 都 没有 过 滤 条 件 。 

SQL 语句 中 A4 与 АЗ 进行 关联 ， 因 为 А4 过 滤 后 返回 6 行 数据 ，A3 是 小 表 ， 所 以 让 А4 
作为 驱动 表 leading(a4)， 与 АЗ УАУ use_ nl(a4,a3) 方 式 进行 关联 ， 关 联 之 后 得 到 一 个 
结果 集 ， 因 为 A4 与 A3 返回 数据 量 都 很 小 ， 所 以 关联 之 后 的 结果 集 也 必然 很 小 。 

因为 А2 表 很 大 ， 而 且 A2 没有 过 滤 条 件 ， 所 以 我 们 不 能 让 А2 Ë HASH 连接 ， 因 为 没有 
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过 滤 条 件 ， 使 用 HASH 进行 关联 只 能 走 全 表 扫 描 。 如 果 让 А2 EREA, IRETI 
动 表 ， 那 么 我 们 可 以 让 А2 走 连 接 列 的 索引 ， 这 样 就 避免 了 大 表 A2 因为 没有 过 滤 条 件 而 走 全 
表 扫 描 。 因 此 ， 我 们 将 A4 АЗ 关联 之 后 的 结果 集 作为 幅 套 循环 驱动 表 ， 然 后 再 与 A2 使 用 
几 套 循环 进行 关联 :， use_nl(a3,a2)。 

因为 AS 过 滤 后 有 6 万 行 数据 ， 所 以 我 们 让 AS 与 А2 进行 HASH 连接 ， 最 终 添 加 如 下 
HINT。 


SELECT "AL", "CODE", 
FROM (SELECT 





"А1". "DEVICE "A1"."VERSION" 





D", 





"Al"."SIDEB PORT ID", 
1(а4,а3) 








A " ж п CO E" "C DE " p 

"A2"."DEVICE ID" "DEVICE ID", 
"A2"."SIDEB PORT ID" "SIDEB PORT ID", 
"A3"."VERSION" "VERSION", 


ROW NUMBER() OVER(PARTITION BY "A4"."PROD ID" ORDER BY "А4"."НІ5Т TIME" DES 








©) "RN" 
FROM "RM"."H PROD 2 RF SERV" "д4", 
"RM","H КӘС FACING SERV LINE ITEM" "АЗ", 
"RM" . "CONNECTOR" Baan 
WHERE "A4","SERV ID" = "АЗ". "БЕВУ ID" 
AND "A3"."LINE Ір" = "А2", "СОММЕСТОБ Ір" 
AND EXISTS (SELECT паз 88777 0 
FROM "RM"."DEVICE ITEM" "AS" 
WHERE "A5"."DEVICE ID" = "A2"."DEVICE ID" 
AND "А5"."ІТЕМ SPEC ID" = 200006 
AND "AS"."VALUE" ='7') 
AND "A4"."PROD ID" - 313) "A1" 
WHERE "Al"."RN" = 1; 
执行 计划 如 下 。 
Id|Operation | Name Rows | Bytes | Cost ($CPU) 
O|SELECT STATEMENT | 1 148 40 (3) | 
1| VIEW 1 175 40 (3) 
g WINDOW SORT PUSHED RANK 1| 109 40 (3) 
3 HASH JOIN SEMI 1 1091 39 (0) 
ЕТ. NESTED LOOPS | ah 59111 :33 (0) 
М NESTED LOOPS | 7 308 19 (0) 
| & TABLE ACCESS BY INDEX ROWID|H PROD 2 RF SERV 4 96 q 51 
* 7 INDEX RANGE SCAN IDX HP2RS PRODID SERVID 4 3 (0) 
8 TABLE ACCESS BY INDEX ROWID|H RSC FACING SERV LINE ITEM 2| 40 4 (0) 
* 9 INDEX RANGE SCAN IDX HRFSLI SERV 2| 2 (0) 
10 TABLE ACCESS BY INDEX ROWID|CONNECTOR 1| 29 2 (0) 
ЖС INDEX UNIQUE 5САМ PK CONNECTOR 1 1 (0) 
*12 TABLE ACCESS BY INDEX ROWID |DEVICE ITEM 1 36 6 (0) 
*13 INDEX RANGE SCAN IDX DEVICE ITEM VALE 9 4 (0) 




















Predicate Information (identified by operation id): 


1 一 filter("A1"."RN"-1) 

д = filter (КОИ NUMBER() OVER ( PARTITION BY "А4", "РКОр Ір" ORDER BY 
INTERNAL FUNCTION ("А4"."НІЅТ TIME") DESC )<=1) 

3 - access("A5",."DEVICE ID"-"A2"."DEVICE ID") 

7 = access("A4","PROD 1р"=313) 

9 = access("A4","SERV ID"-"A3"."SERV ID") 
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11 - access("AS",."LINE ID"-"A2"."CONNECTOR ID") 
12 - filter("A5","TTEM SPEC ID"-200006) 
13 - access ("A5","VALUE"-'7") 


Statistics 
0 recursive calls 
0 db block gets 
14770 consistent gets 

0 physical reads 
0 redo size 

735 bytes sent via SQL*Net to client 

492 bytes received via SQL*Net from client 
2  SQL*Net roundtrips to/from client 
1 sorts (memory) 
0 sorts (disk) 
1 rows processed 


最 终 该 SQL 只 需 0.188 ЮЙ НЕШ АЕ Ж, GERE EOT ARR 2 539 920 下 降 到 14 770. 

当 具 备 一 定 优化 理论 知识 之 后 ,我 们 可 以 不 看 执行 计划 ， 直 接 根据 SQL 写法 找到 SQL 语 
句 中 返回 数据 量 最 小 的 表 作为 驱动 表 , 然后 看 它 与 谁 进行 关联 , 根据 关联 返回 的 数据 量 判断 走 
NL 还 是 HASH, 然后 一 直 这 样 进行 下 去 ， 直 到 SQL 语句 中 所 有 表 都 关联 完毕 。 如 果 大 家 长 期 
采用 此 方法 进行 锻炼 ， 久 而 久之 ， 你 自己 的 脑袋 就 是 CBO。 





本 案例 发 生 在 2011 年 ， 当 时 作者 罗 老 师 在 惠普 担任 开发 DBA， 支 撑 宝 洁 公 司 的 数据 仓 
库 项 目 。 为 了 避免 泄露 信息 ， 他 对 SQL 语句 做 了 适当 修改 。Obiee 终端 用 户 发 来 邮件 说 某 报 
表 执 行 了 30 分 钟 还 不 出 结果 ， 请 求 协助 。 通 过 与 Obiee 开发 人 员 合作 ， 找 到 报表 SQL 语句 
如 下 。 


select sum(T2083114.MANUL COST OVRRD AMT) as cl, 
sum(nvl(T2083114.REVSD VAR ESTMT COST AMT , 0)) as c2, 
T2084525.ACCT LONG NAME as c3, 

Т2084525.МАМЕ as c4, 

T2083424.PRMTN NAME as c5, 

T2083424.PRMTN ID as c6, 

case when case when T2083424.CORP PRMTN TYPE CODE - 'Target Account' 
then 'Corporate' else T2083424.CORP PRMTN TYPE CODE end is null 

then 'Private' else case when T2083424. CORP | PRMTN ' TYPE CODE = 'Target Account' 
then 'Corporate' else T2083424.CORP PRMTN TYPE | CODE end end as cT, 
T2083424.PRMTN STTUS CODE as c8, 

T2083424.APPRV BY DESC as c9, 

T2083424.APPRV STTUS CODE as c10, 

T2083424.AUTO UPDT GTIN IND as cll, 

T2083424.CREAT DATE as c12, 

T2083424.PGM START DATE as с13, 

T2083424.PGM END DATE as с14, 

nvl(case when T2083424. PRMTN STTUS CODE - 'Confirmed' 

then cast(( TRUNC( TO | DATE('2011- 06-07!" ‚ 'YYYY-MM-DD') ) - TRUNC( T2083424.PGM END D 
ATE ). ) as VARCHAR: ( 10 ) ) end a '') as.ci5, 

T2083424.PRMTN STOP DATE as с16, 

T2083424. SHPMT START | DATE аз c17, 

Т2083424. SHPMT END DATE as с18, 
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T2083424.CNBLN ИК СМТ as c19, 

T2083424. АСТУУ | РЕТІ | POP as c20, 

T2083424. CMMNT ` DESC as c21, 

Т2083424.РЕМТМ AVG POP as c22, 

T2084525.CHANL TYPE DESC as c23, 

T2083424.PRMTN SKID as c24 

from 

ОРТ АССТ FDIM T2084525 /% ОРТ АССТ PRMTN FDIM */ , 

ОРТ BUS UNIT ЕРІМ 72083056, 

ОРТ CAL MASTR DIM T2083357 /* ОРТ CAL MASTR DIMO1 */ , 

OPT PRMTN FDIM T2083424, 

ОРТ ACTVY FCT T2083114 

where  (T2083056.BUS UNIT SKID - T2083114.BUS UNIT SKID and T2083114.BUS UNIT SKID - 
T2084525.BUS UNIT SKID 

and T2083114.DATE SKID = T2083357.CAL MASTR SKID and T2083114.BUS UNIT SKID = Т208342 
4.BUS UNIT SKID 

and T2083114.PRMTN SKID - T2083424.PRMTN SKID and T2083056.BUS UNIT NAME - 'Chile' 
and T2083114.ACCT PRMTN SKID - T2084525.ACCT SKID and T2083357.FISC YR ABBR NAME - 'F 
Y10/11' 

and T2084525.ACCT LONG NAME is not null and (case when T2083424.CORP PRMTN TYPE CODE 
- 'Target Account' 

then 'Corporate' else T2083424.CORP PRMTN TYPE CODE end іп ('Alternate BDF', 'Corpor 
ate', 'Private')) 

and (T2084525.ACCT LONG NAME in ('ADELCO - CHILE - 0066009018', 'ALIMENTOS FRUNA - CH 
ILE - 0066009049', 

'CENCOSUD - CHILE - 0066009007', 'COMERCIAL ALVI - CHILE - 0066009070', 'D&S - CHILE 
- 0066009008', 

'DIPAC - CHILE - 0066009024', 'DIST. COMERCIAL - CHILE - 0066009087', 'DISTRIBUCION L 

AGOS S.A. - CHILE - 2001146505', 

'ECOMMERCE ESCALA 1 - 1900001746', 'EMILIO SANDOVAL - CHILE - 2000402293', 'F. AHUMAD 

A - CHILE - 0066009023', 

'FALABELLA - CHILE - 2000406971', 'FRANCISCO LEYTON - CHILE - 0066009142', 'MAICAO - 
CHILE - 0066009135', 

'MARGARITA UAUY - CHILE - 0066009146', 'PREUNIC - CHILE - 0066009032', 'PRISA DISTRIB 
UCION - CHILE - 2001419970', 

'RABIE - CHILE - 0066009015', 'S Y B FARMACEUTICA S.A. - CHILE - 2000432938', 

'SOC. INV. LA MUNDIAL LTDA - CHILE - 2001270967', 'SOCOFAR - CHILE - 0066009028', 
'SODIMAC - CHILE - 2000402358', 'SOUTHERN CROSS - CHILE - 2002135799', 

'SUPERM. MONSERRAT - CHILE - 0066009120', 'TELEMERCADOS EUROPA - CHILE - 0066009044")) 

and T2083424.PRMTN LONG NAME in (select distinct T2083424.PRMTN LONG NAME as cl 

from 

ОРТ ACCT FDIM T2084525 /% ОРТ ACCT PRMTN ЕРІМ */ , 

OPT BUS UNIT FDIM T2083056, 

ОРТ CAL MASTR DIM T2083357 /* ОРТ CAL MASTR DIMO1 */ , 

OPT PRMTN FDIM T2083424, 

OPT PRMTN PROD FLTR LKP T2083698 

where ( T2083056.BUS UNIT SKID = T2083698.BUS UNIT SKID and T2083357.CAL MASTR SKID 

= T2083698.DATE SKID 

and T2083698.ACCT PRMTN SKID = T2084525.ACCT SKID and T2083424.PRMTN SKID = T2083698. 


PRMTN SKID 

and T2083424.BUS UNIT SKID = Т2083698.В05 UNIT SKID and T2083056.BUS UNIT NAME = 'Chi 
le' 

and T2083357.FISC YR ABBR NAME = 'FY10/11' and T2083698.BUS UNIT SKID = T2084525.BUS 
UNIT SKID 


and (case when T2083424.CORP PRMTN TYPE CODE - 'Target Account' then 'Corporate' 
else T2083424.CORP PRMTN TYPE CODE end іп ('Alternate BDF', 'Corporate', 'Private')) 
and (T2084525.ACCT LONG NAME in ('ADELCO - CHILE - 0066009018', 

'ALIMENTOS FRUNA - CHILE - 0066009049', 'CENCOSUD - CHILE - 0066009007', 

'COMERCIAL ALVI - CHILE - 0066009070', 'D&S - CHILE - 0066009008', 

'DIPAC - CHILE - 0066009024', 'DIST. COMERCIAL - CHILE - 0066009087', 

'DISTRIBUCION LAGOS S.A. - CHILE - 2001146505', 'ECOMMERCE ESCALA 1 - 1900001746', 
'EMILIO SANDOVAL - CHILE - 2000402293', 'F. AHUMADA - CHILE - 0066009023', 
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'FALABELLA - CHILE - 2000406971', "FRANCISCO LEYTON - CHILE - 0066009142', 

'MAICAO - CHILE - 0066009135', 'MARGARITA UAUY - CHILE - 0066009146', 

'PREUNIC - CHILE = 0066009032', 'PRISA DISTRIBUCION - CHILE .= 2001419970', 

'RABIE - CHILE - 0066009015', 'S Y B FARMACEUTICA S.A. - CHILE - 2000432938', 

'SOC. INV. LA MUNDIAL LTDA - CHILE - 2001270967', 'SOCOFAR - CHILE - 0066009028', 
'SODIMAC - CHILE - 2000402358', 'SOUTHERN CROSS - CHILE - 2002135799', 

'SUPERM. MONSERRAT - CHILE ~ 0066009120', 'TELEMERCADOS EUROPA - CHILE - 0066009044!) 
1 a OR 

group by T2083424.PRMTN SKID, T2083424.PRMTN ID, T2083424.PRMTN NAME, T2083424.SHPMT 
END DATE, 

T2083424.SHPMT START DATE, T2083424.PRMTN STTUS CODE, T2083424.APPRV STTUS CODE, T208 
3424.CMMNT DESC, 

T2083424.PGM START DATE, T2083424.PGM END DATE, T2083424.CREAT DATE, T2083424.APPRV B 
Y DESC, 

T2083424.AUTO UPDT GTIN IND, T2083424.PRMTN STOP DATE, T2083424.ACTVY DETL POP, T2083 
424.CNBLN WK CNT, 

T2083424.PRMTN АУС POP, T2084525.NAME, T2084525.CHANL TYPE DESC, T2084525.ACCT LONG М 
AME, 

case when case when T2083424.CORP PRMTN TYPE CODE = 'Target Account' then 'Corporate' 
else T2083424.CORP PRMTN TYPE CODE end is null then 'Private' else case 

when T2083424.CORP PRMTN TYPE CODE = 'Target Account' then 'Corporate' 

else T2083424.CORP PRMTN TYPE CODE end ега, 

nvl(case when T2083424.PRMTN STTUS CODE - 'Confirmed' 

then cast(( TRUNC( TO DATE('2011-06-07' , 'YYYY-MM-DD') ) - TRUNC( T2083424.PGM END D 
ATE ) ) as VARCHAR ( 10 ) ) end , "") 

order by c24, c3; 


该 SQL 是 Obiee 报表 工具 自动 生成 的 ， 所 以 看 起 来 有 些 凌 乱 。 对 于 很 长 的 SQL， 我 们 可 
以 运用 SQL 三 段 分 拆 方法 ， 快 速 查看 SQL 写法 有 没有 性 能 问题 。 经 过 检查 ，SQL 写法 没有 任 
何 问题 。 检 查 完 SQL 写法 之 后 ， 我 们 没有 直接 检查 执行 计划 ， 因 为 执行 计划 也 比较 长 ， 因 此 
使 用 自己 编写 的 脚本 抓 出 该 SQL 要 用 到 的 表 信息 ， 如 下 所 示 。 


ТАВЬЕ_МАМЕ Size (Mb) PARTITIONED DEGREE NUM ROWS 
*OPT BUS UNIT FDIM .001037598 NO 1 16 

*OPT CAL MASTR DIM 38.1284523 NO 1 37435 
ОРТ CAL MASTR DIM 38.1284523 NO 1 37435 
*OPT PRMTN FDIM 74.6365929 YES 1 52140 
OPT PRMTN FDIM 74.6365929 YES 1 52140 
OPT ACTVY FCT 19.3430614 YES 1 157230 
*OPT ACCT FDIM 36.6709185 YES 2 95415 
OPT ACCT FDIM 36.6709185 YES 2 95415 
OPT PRMTN PROD FLTR LKP 1523.87207 YES 2 30148975 


“*»” 号 表示 该 表 在 执行 计划 中 使 用 到 了 索引 。 一 般 情况 下 ， 只 有 大 表 才 会 引发 SQL 性 能 问 
题 ，SQL 中 ОРТ PRMTN PROD FLTR LKP 表 走 的 是 全 表 扫 描 ， 有 3 000 万 行 数 据 ，1.5GB， 
其 他 表 都 是 小 表 。 需 要 说 明 的 是 ， 表 OPT PRMTN PROD FLTR LKP 大 小 应 该 不 止 1.5GB， 因 
为 当时 没有 通过 DBA SEGMENTS 来 获取 表 大 小 ， 而 是 通过 DBA TABLES 中 NUM ROWS* 
АУС ROW LEN* 估算 得 来 ， 因 为 OPT PRMTN PROD FLTR LKP 是 一 个 分 区 表 ， 
DBA_TABLES 中 的 统计 不 是 十 分 准确 。 找 到 大 表 之 后 ， 在 我 们 查看 执行 计划 的 时 候 首 先 就 应 该 
关注 大 表 ，SQL 的 执行 计划 如 图 9-9 所 示 〔 因 为 执行 计划 比较 长 ， 所 以 采用 截图 方式 并 且 省 略 
了 谓词 )。 
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Id Operation Name Rows Bytes | Cost (%CPU) Time Pstart| Pstop 
0 | SELECT STATEMENT 1 352 1561 (17) 00:00:07 | 
1 | SORT GROUP BY | 1 352 | 1551 (17) 00:00:07 
2| УБИ VM NWYW 2 1 352 1560 (17) 00:00:07 | 
3 | HASH UNIQUE | 1 652 1550 (17)! 00:00:07 | 
4 NESTED LOOPS 
5 NESTED LOOPS 1 652 1549 (17)| 00:00:07 | 
6 NESTED LOOPS 1 639 1548 (17) 00:00:07 
7 NESTED LOOPS 2 1180 1546 (17) 00:00:07 
8 1 130 (5) 00:00:01 
9 N 1 509 109 (6) 00:00:01 
10 à 1 484 108 (6) 00:00:01 
* 11 JOIN 5 830 103 (6) 00:00:01 
12 PARTITION LIST ашы 47 | 4089 82 (3) 00:00:01 КЕҮ(50) КЕҮ(50) 
13 INLIST ITERATOR 
14 TABLE ACCESS BY LOCAL INDEX ROWID ОРТ ACCT FDIM 47 4089 82 (3)! 00:00:01 |KEY(SQ) КЕҮ(50) 
* 15 INDEX RANGE SCAN OPT ACCT FDIM ХХ2 47 43 (5) 00:00:01 КЕҮ(50) KEY(SQ) 
16 NESTED LOOPS 10482 808K 20 (15) 00:00:01 
ы; NESTED 1 40 2 (0) 00:00:01 
(ж 18 INDEX RANGE SCAN OPT BUS UNIT FDIM UX2 1 26 1 (0) 00:00:01 
|* 19 INDEX RANGE SCAN ОРТ BUS UNIT FDIM tX2 1 14 1 (0) 00:00:01 
|, 26 | PARTITION LIST ITERATOR 10482 | 1699K 18 (17), 00:00:01 KEY KEY 
[* 21 | TABLE ACCESS FULL. OPT ACTVY FCT 10482 1699Қ | 18 (17)| 00:00:01 | KEY 
* 22 | TABLE ACCESS BY GLOBAL INDEX ROWID | OPT PRMTN FDIM 1 318 1 (0) 00:00:01 | ROWID | ROWID 
|ж 23 INDEX MINE SCAN OPT PRMTN ЕРІМ PK 1 0 (0) 00:00:01 
* 24 TABLE E SS ROWID | OPT CAL MASTR DIM 1 25 1 (0) 00:00:01 
l+ 25 INDEX АПШЕ SC ОРТ CAL. MASTR. DIM PK 1 0 (0) 00:00:01 
26 PARTITION LIST A 1 59 21 (0) 00:00:01 1 17 
* 27 TABLE ACCESS BY LOCAL INDEX ROWID OPT PRMTN FDIM 1 59 21 (0) 00:00:01 1 17 
* 28 BEX-RÁNGE-SCAM- OPT PRMTN FDIM NX3 4 17 (0) 00:00:01 1 17 
29 PARTITION LIST ITERATOR 39 858 1416 (18) 00:00:07 KEY KEY 
i% 30 КИЕ ACCESS FULL 39 858 1416 (18) 00:00:07 КЕҮ КЕҮ 
ж 31 TABI PEEGS-PX-GEORTT INDEX ROWID 1 49 1 (0) 00:00:01 | ROWID | ROWID 
|* 32 INDEX UNIQUE SCAN OPI ACE] FD PK 1 0 (0) 00:00:01 
* 33 Sen UNIQUE. SCAN OPT CAL MASTR DIM PK 1 0 (0) 00:00:01 
* 34 ABLE ACCESS BY INDEX ROWID OPT LCAL MASTR | DIM 1 13 1 (0) 00:00:01 





19-9 SQL 执行 计划 


Id=30 就 是 大 表 在 执行 计划 中 的 位 置 ，Id=29 是 Id=30 的 父亲 ， 它 与 Id-8 对 齐 。Id=7 ÆR 
套 循 环 , 它 是 Id=8 与 Id=29 的 父亲 。 通 过 分 析 执 行 计划 , 我 们 发 现 OPT PRMTN PROD FLTR_ 
LKP 做 了 舱 套 循环 〈Id=7) 的 被 驱动 表 ， 而 且 没 有 走 索 引 ， 这 就 是 为 什么 Obiee 报表 执行 了 
30 分 钟 还 没 执 行 完毕 。 我 们 查看 Id=30 的 过 滤 条 件 如 下 。 


30 = filter("T2083056"."BUS UNIT SKID"-"T2083698"."BUS UNIT SKID" AND 
"T2083424". "PRMTN | SKID"-"T2083698". "PRMTN SKID" AND 
"T2083424"."BUS | UNIT | SKID"-"T2083698". "BUS - UNIT SKID") 


我 们 根据 过 滤 条 件 创建 索引 从 而 让 NL 被 驱动 表 走 索引 。 


SQL» create index ОРТ PRMTN PROD FLTR LKP NX1 ОМ ОРТ PRMTN PROD FLTR LKP(BUS UNIT SKI 
D,PRMTN SKID) nologging parallel ; 


Index created. 


Elapsed: 00:00:33.04 


创建 索引 花 了 33 分 钟 ， 如 图 9-10 所 示 ， 我 们 再 来 看 一 下 SQL 的 执行 计划 ， 查 看 带 有 
A-TIME 的 执行 计划 。 

创建 完 索 引 之 后 ,Obiee 报表 能 在 4 分 钟 内 执行 完 所 有 数据 。 我 们 注意 观察 执行 计划 Id=11， 
优化 器 评估 返回 5 行 数据 , 但 是 实际 上 返回 了 11248 行 数 据 , 这 导致 后 续 表 连 接 方式 全 采用 了 
REMA. 14-11 是 两 表 HASH 连接 之 后 的 结果 集 ， 如 果 能 够 纠正 Id=11 估算 Rows 的 误差 ， 

那么 优化 器 应 该 能 够 自我 优化 该 报表 。Id=11 是 两 个 表 中 两 个 列 关 联 的 结果 集 ， 优 化 器 一 般 对 

多 个 列 进行 Rows 估算 的 时 候 通常 容易 算 错 ， 于 是 对 Id=11 中 两 个 表 的 连接 列 收集 了 扩展 统计 
信息 。 
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948 扩展 统计 信息 优化 案例 
Id Operation | Name | Starts | E-Rows | A-Rows |  A-Time 
| 9 | SELECT STATEMENT | | 11 | 1824 |00:02:42. 23 
1 | SORT GROUP BY | 1 | 1| 1324 |00:02:42. 23 
2| VM_NWVW 2 | 1! 1| 6808 (00:02:42. 18 
| 3,  HASH UNIQUE | | 1 | 1| 6808 (00:02:42. 18 
| 4 NESTED LOOPS | 1] | 8220K|00:02:21.06 
| БҮ NESTED LOOPS | 1 1 | 5220K 00:02:00. 18 
176) NESTED LOOPS 1! 1 | 00:01: 
| т! NESTED 100Р5 | 1! 2| :18.42 | 
8 | NESTED LOOPS | 1 | ы 201. 
| 9| NESTED LOOPS | 1j 1| 1 | 
10 NESTED LOOPS | 1 | 00:00:00. 40 
* 11 | HASH JOIN ң СҮТ 1248200: 00:00.07 | 
12 PARTITION LIST SUBQUERY | i| 5 00:00:00. 01 
13 | INLIST ITERATOR | 11 | 25 00:00:00. 01 
14 | TABLE ACCESS BY LOCAL INDEX ROWID OPT ACCT ЕРІМ | 25 | 4T | 25 100:00:00.01 
* 15 | INDEX RANGE SCAN OPT ACCT FDIM NX2 | 25 4Т | 25 00:00:00. 01 
16 | NESTED LOOPS | 1 | 10482 | 12788 |00:00:00.03 
17 | NESTED LOOPS | 11 1 | 1 100:00:00. 01 
* 18 | INDEX RANGE SCAN | OPT BUS UNIT FDIM UX2 | 11 1 | 1 |00:00:00. 01 
*19 | INDEX RANGE SCAN OPT BUS UNIT ЕРІМ UX2 | 1| 1| 1 100:00:00.01 
20 | PARTITION LIST ITERATOR | | 1 | 10482 | 12788 |00:00:00.03 
|* 21 | TABLE ACCESS FULL | ОРТ_АСТҮҮ РСТ 1 10482 | 12788 |00:00:00.03 
*22 | TABLE ACCESS BY GLOBAL INDEX КӨШІ) | OPT РЕМТХ FDIM | 11248 | 1 | 11248 00:00:00. 31 
*28 | INDEX UNIQUE SCAN | ОРТ PRMTN ЕРІМ PK 11248 | 1 | 11248 00:00:00.12 
* 24 TABLE ACCESS BY INDEX ROWID | OPT CAL MASTR DIM 11248 | 1 | 6808 00:00:00. 14 
* 25 INDEX UNIQUE SCAN | OPT CAL MASTR DIM PK | 11248 | 1 | 11248 |00:00:00.05 
26 PARTITION LIST ALL | 6808 | 1 | 6808 (00:00:01.08 
* 27 TABLE ACCESS BY LOCAL INDEX ROWID — | ОРТ PRMIN ЕРІМ 115K| 1| 6808 00:00:01.05 
* 28 INDEX RANGE SCAN | OPT PRMTN FDIM NX3 | 115К| 4 | 6808 00:00:00. 78 
29 TABLE ACCESS BY GLOBAL INDEX ROWID | OPT PRMTN PROD FLTR LKP | 6808 | 39 |  8220K|00:01:19. 79 
* 30 INDEX RANGE SCAN | OPT PRMTN PROD FLTR LKP NX1 | 6808 3 | 5220K 00:00:43. 96 
* 31 TABLE ACCESS BY GLOBAL INDEX ROWID | OPT. ACCT ЕРІМ |  5220K| 1|  85220K|00:00:23. 79 
ж 32 INDEX UNIQUE SCAN OPT ACCT FDIM PK 5220K 1|  8220K|00:00:08.38 
* 33 INDEX UNIQUE SCAN OPT CAL MASTR DIM PK 5220K 1| 5220К|00:00:07. 58 
* 34 TABLE ACCESS BY INDEX ROWID OPT CAL MASTR DIM 5220K 1 | 5220к100:00:17. 28 





Predicate Information (identified by operation id): 





11 - access(^T2083114". "BUS UNIT SKID^-^ 


图 9-10 


SQL» SELECT DBMS STATS.CREATE EXTENDED STATS (USER, 


ACCT SKID)") 


DBMS STATS.CREATE EXTENDED STATS(USER,'OPT ACCT FDIM' 


FROM DUAL; 


12084525". "BUS UNIT SKID" AND "72083114”, "ACCT PRMTN SKID"-"T2084525". "АССТ SKID") 


'OPT ACCT FDIM', '(BUS UNIT SKID, 


,'(BUS UNIT SKID,ACCT SKID)') 


SYS 5ТІ/0800%Х2ІРА B9 СН00В046Т 


SQL» SELECT DBMS STATS.CREATE EXTENDED STATS (USER, 


ACCT PRMTN SKID)') 


DBMS STATS.CREATE EXTENDED STATS(USER,'OPT ACTVY FCT' 


9:74 


FROM DUAL; 


'OPT ACTVY FCT', '(BUS UNIT SKID, 


,'(BUS UNIT SKID,ACCT PRMTN SKID 


SYS STUSCVONKK5CCMOW2XEQWSRXSM 


granularity => 'ALL', 


SOL» BEGIN 

2 

3 tabname => 

4 

5 method opt => 
6 degree => 6, 
i 

8 cascade-»TRUE 
9-9“ 
10 END; 
ir 7 


DBMS STATS.GATHER TABLE STATS(ownname => 
'OPT ACCT FDIM', 

estimate percent -» 20, 
'for all columns size auto', 


PL/SQL procedure successfully completed. 


Elapsed: 00:00:57.76 


'XXXXX', 


---H TRE, EPI TEX 
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Ш csse 


SQL> BEGIN 

2  DBMS STATS.GATHER TABLE STATS(ownname => 'XXXX', ---Z TRE, APEK TEK 
3 tabname -» 'OPT ACTVY FCT', 
4 estimate percent => 20, 
5 method opt => 'for all columns size auto', 
6 degree => 6, 
7 granularity => 'ALL', 
8  cascade-»TRUE 
5 Ww 

10 END; 
лу 


PL/SQL procedure successfully completed. 


Elapsed: 00:01:15.10 


收集 完 扩展 统计 信息 之 后 ,SQL 能 在 1 秒 左 右 执行 完毕 , 带 有 A-Time 的 执行 计划 如 图 9-11 























所 示 。 
Id Operation Name Starts | E-Rows | A-Rows | A-Time Buffers 
0 | SELECT STATEMENT 1 | 
| 1 | SORT GROUP BY 1 | 1 | 752 
*2 FILTER 1| (00:00:01. 84 
3 NESTED LOOPS 1 | | 6808 00:00:00.04 | 52722 
4 NESTED LOOPS 1 4 | 11248 |00:00:00.03 | 41474 
5 NESTED LOOPS 1 12 | 11248 (00:00:00.02 | 30247 
* 6 HASH JOIN 1 403 | 11248 |00:00:00.01 172 
1 PARTITION LIST SUBQUERY 1 47 | 25 |00:00:00.01 | 50 
8 | INLIST ITERATOR 1| 25 |00:00:00.01 AT 
9 | TABLE ACCESS BY LOCAL INDEX ROWID| ОРТ АССТ FDIM 25 | AT | 25 00:00:00.01 | 47 
|* 10 INDEX RANGE SCAN | OPT-ACCT FDIM NX2 25 47 | 25 00:00:00.01 27 
| 6 NESTED L 1 | 10508 | 12788 00:00:00.01 122 
* 12 INDEX RANGE SCAN OPT BUS UNIT FDIM UX2 1 1| 1 00:00:00.0 | 1 0 
13 PARTITION LIST ITERATOR 1 | 10508 12788 00:00:00.01 121 
|* 14 TABLE ACCESS FULL OPT ACTVY FCT 1 | 10508 | 12788 |00:00:00.01 121 
* 15 TABLE ACCESS BY GLOBAL INDEX ROWID Pr PRMTN FDIM 11248 | 1 | 11248 |00;00:00.01 30075 
* 16 INDEX LNIQUE SCAN PT_PRMTN FDIM PK 11248 1 | 11248 (00:00:00.01 | 11250 
* 17 INDEX UNIQUE SCAN | OPT CAL MASTR DIM PK | 11248 1 | 11248 00:00:00. 01 11227 
|+ 18 | TABLE ACCESS BY INDEX ROWID | OPT CAL MASTR DIM | 11248 1 | 6808 (00:00:00.01 | 11248 
| 19 | NESTED LOOPS | 6206 | 6206 00:00:01.79 | 158K 
| 20 NESTED | 6206 | 1 | 6206 |00:00:01.79 | 151K 
21 NESTED LOOPS 6206 1 | 6206 |00:00:01.79 | 149K 
22 NESTED LOOPS | 6206 | 5 | 6206 00:00:01. 79 128K 
23 | NESTED LOOPS 6206 1 | 6206 00:00:00.09 103K 
* 24 INDEX RANGE SCAN OPT BUS UNIT FDIM UX2 6206 1 | 6206 00:00:00, 01 6206 
25 PARTITION LIST ALL 6206 1| 6206 00:00:00.09 | 97324 
* 26 TABLE ACCESS BY LOCAL INDEX ROWID т _РЕМТ\ | FI 49648 | 1 | 6206 |00:00:00.09 | 97324 
|* 27 | INDEX RANGE SCAN | OPT PRMTN FDIM NX3 | 49648 4 | 6206 |00:00:00.08 | 7 
| 28 | TABLE ACCESS BY GLOBAL INDEX ROWID | ОРТ PRMIN PROD FLTR LKP | 6206 39 | 6206 (00:00:01.69 | 24825 
* 28 INDEX RANGE SCAN OPT PRMIN PROD FLTR LKP NX1 | 6206 3 | 6206 100:00:01.53 18618 
* 30 TABLE ACCESS BY GLOBAL INDEX ROWID | OPT ACCT ЕРІМ 6206 | 1| 6206 00:00:00.01 17241 
* 931 | INDEX UNIQUE SCAN OPT ACCT FDIM PK 6206 1| 6206 00:00:00.01 11035 
fe 32 | INDEX UNIQUE SCAN OPT CAL MASTR DIM PK 6206 1 | 6206 |00:00:00.01 6211 | 
|ж 33 | TABLE ACCESS BY INDEX ROWID OPT CAL MASTR DIM 6206 | 1| 6206 100:00:00.01 | 6206 | 
图 9-11 


大 家 在 工作 中 如 果 遇 到 多 列 过 滤 或 者 多 列 关 联 Rows 估算 出 现 较 大 偏差 的 时 候 , 不 妨 收 集 
扩展 统计 信息 试 一 试 。 

其 实 当 时 是 项 目 经 理 找到 作者 罗 老 师 来 优化 SQL 的 ， 当 时 他 应 该 是 被 美国 宝洁 的 客户 批 
评 了 。 客 户 的 原 话 是 说 :“ 我 已 经 抽 完 一 支 烟 了 ， 报 表 还 没 打 开 ， 我 原本 以 为 当 我 抽 完 第 二 支 
烟 的 时 候 报 表 能 打开 , 谁 知 当 我 抽 完 第 三 支 烟 的 时 候 报表 还 没 打 开 !7” 罗 老师 优化 完 报表 之 后 ， 
幽默 地 说 了 句 ， 现 在 客户 可 以 在 掏 打火机 、 烟 还 没 点 燃 之 前 就 能 打开 报表 了 。 
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9.19 使 用 LISGAGG 分 析 函 数 优化 WMSYS.WM_CONCAT 


xs › А m 
val 4 
=] 4 

Oe Бы 





with temp as 
(select sgd.detail id id, 
wmsys.wm concat(distinct(sg.gp name)) groupnames, 
wmsys.wm concat(distinct(su.user name)) usernames 
from  sgd 
left join sg 
on sg.id - sgd.gp id 
left join sug 
on sg.id - sug.gp id 
left join зи 
on sug.user id - su.id 
group by sgd.detail id) 
select zh.id, 
zh.id detailid, 
zh.name detailname, 
zh.p level hospitallevel, 
zh.type hospitaltype, 
dza.name region, 
temp.groupnames, 
temp.usernames, 
(case 
when gd.gp id is null then 
0 


else 
1 
end) isalloted 
from zh 
left join аза 
on zh.area id - dza.id 
left join temp 
on zh.id - temp.id 
left join (select gp id, detail id from sys gp detail where gp Id - :0) gd 
on zh.id - gd.detail id order by length(id),zh.id asc; 


该 SQL 返回 20 779 行 数 据 ， 要 执行 4 分 32 秒 。 该 执行 计划 中 全 是 HASH JOIN， 这 里 就 
不 贴 执行 计划 了 。 

首先 这 条 SQL 最 终 返回 20 779 行 数据 ， 该 SQL 语句 最 后 部 分 没有 GROUP BY， 表 与 表 
之 间 关 联 全 是 外 连接 ， 主 表 zh 没有 过 滤 条 件 ， 因 此 判断 zh KEL 20 779 行 数据 ， 因 为 它 是 
外 连接 的 主 表 ,不 管 关 联 有 没有 关联 上 ，zh 会 返回 表 中 全 部 数据 ， 如 果 zh 与 dza 是 En 关系 ， 
那么 zh 表 总 行 数 还 将 少 于 20 779 行 数据 。 同 时 也 判定 dza，TEMP 数据 量 都 不 大 ， 因 为 所 有 
表 关 联 完 只 返回 20779 行 数 据 。 既 然 都 是 小 表 ， 为 什么 最 终 要 执行 4 分 32 秒 呢 ? 遇 到 此 类 问 
题 ， 我 们 需要 将 SQL 拆 开 ， 分 步 执行 ， 这 样 就 能 判断 SQL 中 哪 一 步 是 性 能 瓶颈 。9.10 节 中 案 
例 也 是 采用 分 步 执行 方法 找到 问题 根本 原因 。 

SQL 语句 中 有 个 with аз 子 句 ， 对 其 单独 执行 ， 发 现 要 执行 两 分 钟 左右 。with as 子 句 中 有 
两 个 列 转行 函数 : wmsys.wm_concat, 将 其 注释 之 后 with as 子 句 能 秒 出 。 现 在 我 们 定位 到 , SQL 
性 能 问题 是 由 wmsys.wm_concat 导致 。 对 于 列 转 行 ，Oracle 还 提供 了 Listagg 分 析 函 数 ， 
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wmsys.wm concat 从 Oraclellg 之 后 返回 的 是 Clob 类 型 ， 而 Listagg 返回 的 是 varchar2 类 型 。 
因此 我 们 尝试 对 with as 子 名 进行 等 价 改写 ， 利 用 分 析 函 数 Listagg 代替 wmsys.wm concat, Ul 
验证 改写 之 后 是 否 还 会 出 现 性 能 问题 。with as 子 句 原始 SQL 如 下 。 


select sgd.detail id id, 
wmsys.wm concat(distinct(sg.gp name)) groupnames, 
wmsys.wm concat(distinct(su.user name)) usernames 
from sgd 
left join sg on sg.id - sgd.gp id 
left join sug on sg.id - sug.gp id 
left join su on sug.user id = su.id 
group by sgd.detail id; 


为 with as 子 句 中 有 两 个 wmsys.wm_concat， 而 且 wmsys.wm concat 中 有 distinct, Т0 
Listagg PFF distinct， 所 以 我 们 只 能 一 个 一 个 去 掉 wmsys.wm_concat。 现 在 将 with as 子 句 中 
wmsys.wm concat(distinct(su.user name)) usernames 去 掉 ， 只 保留 wmsys.wm concat(distinct 
(sg.gp name)) groupnames. [Ж] 5 usernames 关联 了 su，sug， 而 现在 只 保留 groupnames, PLA 
我 们 需要 将 su, sug ЖЧ, ЖИГ usernames 的 SQL 如 下 。 


select sgd.detail id id, wmsys.wm concat(distinct(sg.gp name)) groupnames 
from sys gp detail sgd 
left join sys gp sg on sg.id = sgd.gp id 

group by sgd.detail id; 


其 执行 计划 如 下 。 
已 用 时 间 ; 00: 00: 58.04. 
执行 计划 


Plan hash value: 3491823204 


| Id | Operation | Name | Rows | Bytes |TempSpc| Cost ($CPU)| 
| 0 | SELECT STATEMENT | | 20584 | 824К| | 1308 (8) | 
| 1 | SORT GROUP BY | | 20584 | 824K| 15M| 1308 (8) | 
P. 21 HASH JOIN RIGHT OUTER| | 313K| 12M| | 449 (6) | 
| Br | TABLE ACCESS FULL | SYS GP | a^ 69 | | 3 (0) | 
| 4 | TABLE ACCESS FULL | SYS GP DETAIL | 313К| 5518] | 438 (5.1 


2 = access("SG"."ID"(je"5GD"."GP ID") 


统计 信息 







recursive calls 





physical reads 

redo size 

9993548 bytes sent via SQL*Net to client 

6067828 bytes received via SQL*Net from client 
83118  SQL*Net roundtrips to/from client 
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9.19 使 用 LISGAGG 分 析 函 数 优化 WMSYS.WM_CONCAT 


1 sorts (memory) 
0 sorts (disk) 


执行 计划 中 的 db block gets 来 自 于 Clob。 因 为 Listagg 不 支持 distinct， 所 以 我 们 需要 先 去 
重 ， 再 采用 Listagg，Listagg 改写 的 SQL 如 下 。 


select detail id, listagg(gp name, ',') within 
group ( 
order by null) 
from (select sgd.detail id, sg.gp_name 
from sys gp detail sgd 

left join sys gp sg on sg.id - sgd.gp id 

group by sgd.detail id, sg.gp name) 
group by detail id; 


改写 后 的 执行 计划 如 下 。 
已 用 时 间 : 00: 00: 01.12 
执行 计划 


Plan hash value: 147456425 


| Id | Operation | Name | Rows | Bytes |TempSpc| Cost (%CPU) | 
| 0 | SELECT STATEMENT | | 20584 | 1547К| | 1467 (7)1 
| 1 | SORT GROUP BY | | 20584 | 1547К| | 1467 (T) | 
ІР ДЕСІ VIEW | VM NWVW 0 | 43666 | 3283К| | 1467 (7)1 
Í +3 1 HASH GROUP BY | | 43666 | 1748К| 15M| 1467 (7)| 
[+ 441 HASH JOIN RIGHT OUTER| | 313K| 12M| | 449  (6)| 
| >a 553] TABLE ACCESS FULL | SYS_GP | с | 69 | | 3 (0) | 
| 60] TABLE ACCESS FULL | SYS GP DETAIL | 313K| 5518К| | 438 (5) 1 


Predicate Information (identified by operation id): 


4 - access("SG"."ID"(*)s"SGD"."GP ID") 


统计 信息 
1 recursive calls 
0 db block gets 
27115 consistent gets 
0 physical reads 
0 redo size 
450516 bytes sent via SQL*Net to client 
15595 bytes received via SQL*Net from client 
1387  SQL*Net roundtrips to/from client 
1 sorts (memory) 
0 sorts (disk) 
20779 rows processed 


使 用 Listagg 改写 之 后 ，SQL 能 在 1 秒 执行 完毕 ， 而 采用 wmsys.wm concat 需要 58 Ж), 
这 说 明 采 用 Listagg 代替 wmsys.wm_concat 能 达到 优化 目的 。 

下 面 我 们 改写 另外 一 个 wmsys.wm_concat, 改写 的 思路 一 模 一 样 , 先 去 重 , 再 使 用 Listagg。 
| select detail id, listagg(user name, ',') within 


group( 
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"PE _ 


order by null) 
from (select sgd.detail id id, su.user name 
from sgd 
left join sg on sg.id = sgd.gp id 
left join sug on sg.id - sug.gp id 
left join su on sug.user id = su.igd 
group by sgd.detail id, su.user name) 
group by detail id; 


最 终 的 with as 子 句 如 下 。 


select a.detail id id , a.groupnames, b.usernames 
from (select detail id, listagg(gp name, ',') within 
group( 
order by null) groupnames 
from (select sgd.detail id, sg.gp name 
from sys gp detail sgd 
left join sys gp sg on sg.id - sgd.gp id 
group by sgd.detail id, sg.gp name) 
group by detail id) a, 
(select detail id, listagg(user name, ',') within 
group( 
order by null) usernames 
from (select sgd.detail id, su.user name 
from sgd 
left join sg on sg.id - sgd.gp id 
left join sug on sg.id = sug.gp id 
left join su on sug.üser id = su.id 
group by sgd.detail id, su.user name) 
group by detail id) b 
where a.. detail id = b.detail id; 


用 改写 后 的 with as 子 句 替换 原始 SQL 中 的 with as 子 句 ， 最 终 SQL 能 在 两 秒 左 右 执行 
Bs 


at 


在 工作 中 尽量 使 用 Listagg 代替 wmsys.wm concat. 






үү ҮЙҮҮ 
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2014 年 ， 曾 遇 到 一 个 INSTR 优化 案例 。 因 为 当初 SQL 代码 并 非 运 行 在 Oracle 中 ， 所 以 ， 
在 Oracle 中 创建 测试 数据 以 便 演示 该 案例 ， 不 管 是 Oracle 数据 库 还 是 其 他 数据 库 ， 优 化 的 思 
想 都 是 一 样 的 。 

需求 是 这 样 的 : 查找 事实 表 中 URL 字段 包含 了 维度 表 中 URL 的 记录 ,然后 进行 汇总 统计 。 

创建 事实 表 如 下 。 


create table T FACT 
(msisdn number(11), 
url varchar2(50) 

); 


ш ШШ 


插入 测试 数据 。 
insert into T FACT 
select '139' || chr(dbms random.value(48, 57)) || 
chr(dbms random.value(48, 57)) || chr(dbms random.value(48, 57)) || 
chr(dbms random.value(48, 57)) || chr(dbms random.value(48, 57)) || 


9.20 INSTR 非 等 值 关联 优化 案例 


chr(dbms random.value(48, 57)) || chr(dbms random.value(48, 57)), 

lpad(chr(dbms random.value(97, 122)), 
dbms random.value(1, 20), 
chr(dbms random.value(97, 122))) | 

lpad(chr(dbms random.value(97, 122)) || 
chr (dbms_random. value (97, 122)) || 
chr (dbms_random.value (97, 122)) || 
chr (dbms_random. value (97, 122)), 
dbms random.value(4, 20), 
chr(dbms random.value(97, 122))) 

from dual 
connect by rownum «- 10000; 


反复 插入 数据 ， 直 到 表 中 一 共有 128 万 条 数据 。 


begin 
for i dn 1727. Topp 
insert into T FACT 
select * from T FACT; 


commit; 
end loop; 
end; 
在 实际 案例 中 事实 表 有 上 亿 条 数据 ， 演 示 只 取 100 万 条 数据 。 
创建 维度 表 如 下 。 


create table T DIM as 
select cast(rownum as number(6)) code,cast(cl as varchar2(50)) url 
from ( 


select distinct substr(url, -dbms random.value(2, length(url) = 3)) сі 
from T FACT); 


创建 汇总 统计 表 。 


create table T RESULT 
( 

msisdn number(11), 
code number(6), 

url varchar2(50), 

cnt number(6) 

% 


现在 我 们 要 执行 如 下 SQL. ЖИ T FACT 表 中 URL & f. T. DIM 的 记录 。 


insert into T RESULT 
(msisdn, code, url, cnt) 
select tl.msisdn, t2.code, t2.url, sum(1) 
from T FACT tl 
inner join T DIM t2 on instr(tl.url, t2.url) > 0 
group by tl.msisdn, t2.code, t2.url; 


因为 SQL 中 关联 条 件 是 instr, МЕСЕ ЕМ, ЖЕЛЕ HASH 连接 ， 也 不 能 走 排 序 


合并 连接 ， 排 序 合并 连接 一 般 用 于 >=，>，<，<=。 以 上 SQL 执行 计划 如 下 。 


SQL» select * from table(dbms xplan.display); 
PLAN TABLE OUTPUT 


Plan hash value: 2285685195 
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| Та | Operation | Name | Rows | Bytes | Cost ($CPU)| Time 

| 0 | INSERT STATEMENT | | 10G| 798G| 134M (3) |448:22:51 | 
| 1 | LOAD TABLE CONVENTIONAL | T RESULT | | | | | 
| 2: | HASH GROUP BY | | 10G| 798G| 134M  (3)|448:22:51 

| :| NESTED LOOPS | | 106] 7986] 133М (2) |445:43:32 | 
| 4 | TABLE ACCESS FULL | T FACT | 1192K| 45M| 1363 (2) | 00200217 | 
kaba q] TABLE ACCESS FULL [ T DIM |. 8993 | 351K| 112 (2)1 00:00:02 | 


5 = filter(INSTR("T1"."URL","T2"."URL")»0) 


本 书 反复 强调 , UC ЕМ LUCA ЖИЛЕ Ж 51|. 但 是 , 如 果 执 行 计划 是 因为 INSTR. LIKE, 
REGEXP LIK 等 而 导致 的 嵌 套 循环 ， 这 时 被 驱动 表 反 而 不 能 走 索引 。INSTR，LIKE， 
REGEXP LIKE 会 匹配 所 有 数据 ， 走 索引 的 访问 路 径 只 能 是 INDEX FULL SCAN, 而 INDEX 
FULL SCAN 是 单 块 读 ， 全 表 扫 描 是 多 块 读 。 如 果 INDEX FULL SCAN 需要 回 表 ， 这 时 效率 远 
远 不 如 全 表 扫 描 效 率 高 。 如 果 被 驱动 表 走 INDEX FULL SCAN 不 回 表 ， 这 时 我 们 也 可 以 根据 
索引 中 的 索引 列 ， 建立 一 个 临时 表 , 将 需要 的 列 包 含 在 临时 表 中 ,用 临时 表 代替 INDEX FULL 
SCAN， 因 为 临时 表 不 像 索 引 那 样 需 要 存储 根 、 分 文 、 叶 子 节 点 ， 临 时 表 相 比索 引 体积 反而 更 
小 ， 这样 可 以 减少 被 驱动 表 每 次 被 扫描 的 体积 。 被 驱动 表 因为 要 被 反复 扫描 多 次 ，buffer cache 
最 好 要 有 足够 的 空间 用 于 存放 被 驱动 表 ， 从 而 避免 被 驱动 表 每 次 被 扫描 都 需要 物理 VO. 

经 过 上 面 分 析 ， 如 果 从 执行 计划 方向 入 手 ， 我 们 无 法 优化 SQL。 我 们 再 来 看 一 下 原始 SQL 
АЈ. 


insert into T_RESULT 
(msisdn, code, url, cnt) 
select tl.msisdn, t2.code, t2.url, sum(1) 
from T FACT tl 
inner join T DIM t2 on instr(tl.url, t2.url) » 0 
group by tl.msisdn, t2.code, t2.url; 


SQL 语句 中 有 GROUP BY (汇总 )， 事 实 表 与 维度 表 一 般 都 是 N:1 关系 ， 因 为 SQL 语句 
中 有 汇总 ,我们 可 以 先 对 事实 表 进 行 汇总 ,去掉 重 复数 据 ， 然后 再 与 维度 表 关 联 。 因 为 执行 计 
划 中 事实 表 是 驱动 表 , 维度 表 是 被 驱动 表 , 将 事实 表 提 前 汇总 可 以 将 数据 量 大 大 减少 , 这样 我 
们 就 可 以 减少 嵌 套 循环 的 循环 次 数 ， 从 而 达到 优化 目的 。 

事实 表 原 始 数据 为 128 万 行 ， 我 们 对 事实 表 提前 汇总 。 


create table T MIDDLE as select 
msisdn,url,sum(1) cnt 
from T FACT group by msisdn,url; 


提前 汇总 之 后 ， 数 据 从 128 万 行 减少 到 1 万 行 。 
| SQL» select count(*) from T MIDDLE; 


COUNT (*) 
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改写 后 的 SQL 如 下 。 


insert into T RESULT 
(msisdn, code, url, cnt) 
select tl.msisdn, t2.code, t2.url, sum(cnt) 
from T MIDDLE tl 
inner join T DIM t2 on instr(tl.url, t2.url) > 0 
group by +1. msisdn, t2.00de, t2.url; 


对 数据 进行 提前 汇总 之 后 ， 被 驱动 表 T_DIM 只 需要 循环 1 万 次 ， 而 之 前 需要 循环 128 万 
次 ， 性 能 得 到 极 大 提升 。 

如 果 想 要 最 大 程度 优化 INSTR, LIKE, REGEXP LIKE 等 非 等 值 关联 ， 我 们 只 能 从 业务 
角度 入 手 ， 设 法 从 业务 本 身 、 数 据 本 身 着 手 ， 使 其 进行 等 值 连接 ， 从 而 可 以 走 HASH 连接 。 

如 果 业 务 手段 无 法 优化 ， 除了 上 面 讲 到 的 提前 汇总 数据 ,我 们 还 可 以 开启 并 行 查 询 (并 行 
广播 )， 从 而 优化 SQL。 如 果 不 想 开启 并 行 查询 ， 我 们 可 以 对 表 进 行 拆 分 (类 似 并 行 广 播 )， 
人 工 模拟 并 行 查询 ， 从 而 优化 SQL。 我 们 可 以 对 驱动 表 进行 拆 分 ， 也 可 以 对 被 驱动 表 进行 拆 
分 , 但 是 最 好 不 要 同时 拆 分 驱动 表 和 被 驱动 表 ， 因 为 连接 条 件 是 非 等 值 连接 ,同时 拆 分 驱动 表 
和 被 驱动 表 会 导致 交叉 关联 (将 驱动 表 和 被 驱动 表 都 拆 分 为 6 份 ， 会 关联 36 DO. 如果 表 是 非 
分 区 表 ， 我 们 可 以 利用 ROWID 进行 拆 分 。 如 果 表 是 分 区 表 ， 我 们 可 以 针对 分 区 进行 拆 分 。 关 
于 具体 的 拆 分 方法 ， 请 大 家 阅读 8.5 节 内 容 。 


本 案例 为 好 友 南 京 越 烟 (QQ: 843999405) 分 享 。 
一 个 存储 过 程 从 周 五 晚上 执行 了 到 了 周一 还 没有 执行 完 ， 存 储 过 程 代码 如 下 。 


declare 
isMatch Boolean := false; 
dealPnCnt number(10) :- 0; 
begin 
for c no data in (select nbn.no, 6р аз partition_id 
from TMP NBR NO XXXX 
where nbn.level EE = 1 
апа length (nbn. no) = 8) loop 
dealPnCnt :- dealPnCnt + 1; 
for c data in (select nli.*, nl.nbr level id 
from tmp xxx item nli, 
a level item nl2i, 
b level item nl, 
c level item ns21 
where nli.nbr level item id = nl2i.nbr level item id 
and nl2i.nbr level id - nl.nbr level id 
and nl.nbr level id - ns21.nbr level id 
and ns21.area id - c no data.partition id 
and ns21.res spec id = 6039 
and ns21. nbr. level. id between 201 and 208 
tity) loop 
ata expression) then 
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exit; 
end if; 
end loop; 
if mod(dealPnCnt, 5000) = 0 then 
commit; 
end if; 
end loop; 
end; 


ТМР МВА NO XXXX 共有 400w 行 数 据 ，180MB。 


select nli.*, nl.nbr level id 
from tmp xxx item nli, 
a level item п121, 
b level item nl, 
c level item ns21 
where nli.nbr level item id - nl2i.nbr level item id 
and nl2i.nbr level id - nl.nbr level id 
and nl.nbr level id - ns21.nbr level id 
and ns21.area id = с no data.partition id 
and ns21.res spec id - 6039 
and ns21.nbr level id between 201 and 208 
order by nl2i.priority; 


上 面 SQL 查询 返回 43 行 数据 。 

在 5.1 节 提 到 过 ， 垦 套 循 环 就 是 一 个 LOOP 循环 ，LOOP 套 LOOP 相当 于 笛 卡 儿 积 。 该 
PLSQL 代码 中 有 LOOP € LOOP 的 情况 ， 这 就 导致 UPDATE ТМР NBR NO XXXX 要 执行 
(400 7j*43) К, TMP МВК NO XXXX.no 11951, ТМР МВВ NO XXXX 每 次 更 新 都 
要 进行 全 表 扫 描 。 这 就 是 为 什么 存储 过 程 从 周 五 执行 到 周一 还 没 执行 完 。 

大 家 可 能 会 问 ， 为 什么 不 用 MERGE INTO 对 PLSQL 代码 进行 改写 呢 ? PLSQL 代码 中 是 
用 regexp_like(c_no_data.no,c_data.expression) 进 行 关联 的 ， 使 用 like, regexp like 关联 ， 无 法 
Ж HASH 连接 ， 也 无 法 走 排序 合并 连接 ， 两 表 只 能 走 网 套 循 环 并 且 被 驱动 表 无 法 走 索 引 。 如 
果 强 行使 用 MERGE INTO 进行 改写 ， 因 为 该 SQL 执行 时 间 很 长 ， 会 导致 UNDO 不 释放 ， 所 
以 ， 我 们 没有 采用 MERGE INTO 对 代码 进行 改写 。 

大 家 可 能 也 会 问 ， 为 什么 不 对 TMP_NBR_NO_XXXX.no 建立 索引 呢 ? 这 是 因为 关联 更 新 
可 以 采用 ROWID 批量 更 新 ， 所 以 没有 采用 建立 索引 方法 优化 。 

下 面 我 们 采用 ROWID 批量 更 新 方法 改写 上 面 PLSQL， 为 了 方便 大 家 阅读 PLSQL 代码 ， 
先 创建 一 个 临时 表 用 于 存储 43 记录 。 


create table TMP DATE TEST 

( 

expression VARCHAR2 (255) not null, 
nbr level id NUMBER(9) not null, 
priority NUMBER(8) not null 

); 


insert into  TMP DATE TEST 
select nli.expression, nl.nbr level id, priority from tmp xxx item nli, 
a level item nl2i, 
b level item nl, 
с level item ns21 
where nli.nbr level item id - nl2i.nbr level item id 
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and nl2i.nbr level id - nl.nbr level id 
and nl.nbr level id - ns21.nbr level id 
and пв21.агеа id = 69 d 
and ns21.res spec id - 6039 

and ns21.nbr level id between 201 and 208; 


我 们 创建 另外 一 个 临时 表 ， 用 于 存储 要 被 更 新 的 表 的 ROWID 以 及 过 滤 条 件 字 段 。 


create table TMP NBR NO XXXX TEXT 
( 

rid  ROWID, 

no VARCHAR2 (255), 
); 


insert into ТМР МВК NO XXXX TEXT 
select rowid rid,  nbn.no, from ТМР NBR NO XXXX nbn where nbn.level id-1 and le 
ngth(nbn.no)- 8 ; 


改写 之 后 的 PLSQL 代码 如 下 。 


declare 
type rowid table type is table of rowid index by pls integer; 
updateCur sys refcursor; 
v rowid гоміа table type; 
v rowid2 rowid table type; 


begin 
for c no data in (select t.expression, t.nbr level id, t.priority 
from TMP DATE TEST t 
order by 3) loop 
open updateCur for 
select rid 
from TMP NBR NO XXXX TEXT nbn 
where regexp like(nbn.no, c no data.expression); 
loop 
fetch updateCur bulk collect 
into v rowid LIMIT 20000; 
forall i in v rowid.FIRST .. v rowid.LAST 
update TMP NBR NO XXXX 
set level id - c no data.nbr level id 
where rowid - v rowid(i); 
commit; 
exit when updateCur£notfound; 
end loop; 
CLOSE updateCur; 
end loop; 
end; 


改写 后 的 PLSQL 能 在 4 小 时 左右 执行 完 。 有 没有 什么 办 法 进一步 优化 呢 ? 单个 进程 能 在 4 
小 时 左右 执行 完 ， 如 果 开 启 8 个 并 行进 程 ， 那 应 该 能 在 30 分 钟 左右 执行 完 。 但 是 PLSQL 怎么 
开启 并 行 呢 ? 正常 情况 下 PLSQL 是 无 法 开启 并 行 的 ， 如 果 我 们 直接 在 多 个 窗口 中 执行 同一 个 
PLSQL 代码 ， 会 遇 到 锁 争 用 ， 如 果 能 解决 锁 争 用 ， 在 多 个 窗口 中 执行 同一 个 PLSQL 代码 ， 这 
样 就 变相 实现 了 PLSQL 开 并 行 功能 。 在 第 8 章 提 到 过 ， 可 以 利用 ROWID 切片 变相 实现 并 行 。 


select DBMS ROWID.ROWID CREATE(1, c.oid, e.RELATIVE FNO, e.BLOCK ID, 0) minrid, 
DBMS ROWID.ROWID CREATE(1, 
c.oid, 
e.RELATIVE FNO, 
e.BLOCK ID * e.BLOCKS - 1, 
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10000) maxrid 
from dba extents e, 
(select max(data object id) oid 
from dba objects 
where object name = upper('TMP NBR NO XXXX TEXT') 
and owner = upper('RESCZ2') 
and data object id is not null) c 


where e.segment name = 'TMP NBR NO XXXX TEXT' 
and e.owner = 'RESCZ2'; 


但 是 这 时 我 们 发 现 ,切割 出 来 的 数据 分 布 严 重 不 均衡 , 这 是 因为 创建 表 空 间 的 时 候 没 有 指 
定 uniform size 的 Extent。 于 是 我 们 新 建 一 个 表 空 间 ， 指 定 采用 uniform size 方式 管理 Extent。 


create tablespace TBS BSS FIXED datafile 
'/oradata/osstest2/tbs bss fixed 500.dbf' 
size 500M extent management local uniform size 128k; 


我 们 重建 一 个 表 用 来 存储 要 被 更 新 的 ROWID。 


create table RID TABLE 
( 
rowno NUMBER, 
minrid VARCHAR2(18), 
maxrid VARCHAR2 (18) 
)-$ 


我 们 将 ROWID 插入 到 新 表 中 。 


insert into rid table 
select rownum rowno, 
DBMS ROWID.ROWID CREATE(1, c.oid, e.RELATIVE FNO, e.BLOCK ID, 0) minrid, 
DBMS ROWID.ROWID CREATE(1, 
C. old, 
e.RELATIVE FNO, 
e.BLOCK ID + (e. BLOCKS ~ 1, 
10000) maxrid 
from dba extents e, 
(select max(data object id) oid 
from dba objects 
where object name = upper('TMP NBR NO XXXX TEXT') 
and owner - upper('RESCZ2') 
and data object id is not null) c 
where e.segment name = 'TMP NBR NO XXXX TEXT' 


and e.owner = 'RESCZ2'; 
这 样 RID TABLE 中 每 行 指定 的 数据 都 很 均衡 ， 大 概 4 035 条 数据 。 最 终 更 改 的 PLSQL 代码 
如 下 。 
create or replace procedure pro phone grade(flag num in number) 
as 


type rowid table type is table of rowid index Бу pls integer; 

updateCur sys refcursor; 

v rowid rowid table type; 

v rowid2 гоміа table type; 
begin 

for rowid cur in (select * from rid table where mod(rowno, 8)-flag num 

loop 

for c no data in (select t.expression, t.nbr level id, t.priority from TMP DATE 
TEST t order by 3 ) 
loop 
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open updateCur for select rid,rowid from TMP NBR NO XXXX TEXT прп 
where rowid between rowid cur.minrid and rowid cur.maxrid 
and regexp like(nbn.no, c no data.expression); 
loop 
fetch updateCur bulk collect into v rowid, v rowid2 LIMIT 20000; 
forall i in v rowid.FIRST ..v rowid.LAST 
update TMP МВК NO XXXX set level id = c no data.nbr level id where r 
owid = v rowid(i); 
commit; 
exit when  updateCur$notfound; 
end loop; 
CLOSE updateCur; 
end loop; 
end loop; 
end; 


然后 我 们 在 8 个 窗口 中 同时 运行 以 上 PLSQL 代码 。 
begin 


pro phone grade (0); 
end; 


begin 
pro phone grade(1); 
end; 


begin 
pro phone grade(2); 
end; 


begin 
pro phone grade (7); 
end; 


最 终 我 们 能 在 29 分 钟 左右 执行 完 所 有 存储 过 程 。 本 案例 经 典 之 处 就 在 于 ROWID 切片 实 
现 并 行 ， 同 时 考虑 到 了 数据 分 布 对 并 行 的 影响 ， 其 次 还 使 用 了 ROWID 关联 更 新 技巧 。 


在 做 报表 开发 的 时 候 , 有 时 我 们 会 遇 到 这 样 的 需求 : 不 同 权限 的 账户 各 自 对 应 不 同 的 权限 ， 
从 而 看 到 不 同 的 数据 ， 这 时 我 们 一 般 会 采用 Row Level Security 实现 这 样 的 需求 。2011 年 ， 作 
者 罗 老 师 在 惠普 的 时 候 ， 遇 到 过 多 起 Row Level Security 引发 的 SQL 性 能 问题 。 

Obiee 报表 开发 人 员 发 来 邮件 反映 ， 使 用 权限 较 低 的 账户 打开 报表 非常 缓慢 ， 报 表 运行 了 
15 分 钟 还 没 响 应 ; 而 使 用 权限 最 高 的 账户 ， 报 表 可 以 在 16 秒 内 执行 完毕 。 执 行 缓慢 的 Sel 
代码 如 下 。 


select sum(nvl1(T1796547.ACTL GIV AMT , 0)) as c1, 

Т1792779.АССТ LONG NAME as c2, 

T1792779.NAME as c3, 

T1796631.PRMTN NAME as c4, 

T1796631.PRMTN ID as c5, 

case when case when T1796631.CORP PRMTN TYPE CODE = 'Target Account' then 'Corporat 
е! else T1796631.CORP PRMTN TYPE CODE end із null then 'Private' else 
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case when T1796631.CORP PRMTN TYPE CODE = 'Target Account' then 'Corporate' else T17 
96631.CORP PRMTN TYPE CODE end end аз сб, 

Т1796631.РЕМТМ STTUS CODE as c7, 

T1796631. RPPRV BY | DESC as c8, 

T1796631.APPRV STTUS CODE as c9, 

T1796631.AUTO UPDT GTIN IND ав с10, 

T1796631.CREAT DATE as cll, 

T1796631.PGM START DATE as c12, 

T1796631.PGM END DATE as с13, 

nvl(case when T1796631.PRMTN STTUS CODE - 'Confirmed' then cast(( TRUNC( TO DATE('20 
11-04-26' , 'YYYY-MM-DD') ) - TRUNC( T1796631.PGM END DATE ) ) as 
VARCHAR ( 10 ) ) end , "") as с14, 

T1796631.PRMTN STOP DATE as с15, 

T1796631.SHPMT START DATE as c16, 

T1796631.SHPMT END DATE as с17, 

T1796631.CNBLN ИК СМТ as с18, 

T1796631.ACTVY РЕТІ POP as с19, 

T1796631.CMMNT DESC as c20, 

71796631. PRMTN . AVG POP as c21, 

T1792779.CHANL TYPE DESC as c22, 

T1796631.PRMTN SKID as c23 

from 

ОРТ АССТ FDIM T1792779 /* ОРТ АССТ PRMTN FDIM %/, 

ОРТ BUS UNIT FDIM 71796263, 

ОРТ CAL MASTR DIM T1796564 /% ОРТ CAL MASTR DIMOl */ , 

OPT PRMTN FDIM T1796631, 

OPT BASLN FCT T1796547 

where ( Т1792779. АССТ SKID = Т1796547.АССТ SKID 

and T1792779.BUS UNIT SKID = T1796547.BUS UNIT SKID 

and T1796263.BUS UNIT SKID - T1796547.BUS UNIT SKID 

and T1796547.WK SKID = T1796564.CAL _MRSTR SKID 

and T1796547.BUS UNIT SKID - T1796631.BUS | UNIT SKID 

and T1792779.ACCT LONG NAME = 'FN-AEON GROUP(JUSCOJ4) (C005) - 1900001326' 
and T1796263.BUS UNIT NAME - 'Japan' 

and T1796547.PRMTN SKID - T1796631.PRMTN SKID 

and T1796564.FISC YR ABBR NAME = 'FY10/11' 

and T1792779.ACCT LONG NAME is not null 








547.acct skid IN (select org.org skid from (SELECT DISTINCT ap.org skid 
FROM opt acct postn lkp ap, opt party persn lkp pp, opt user lkp u 
WHERE ap.postn id - pp.party id 
AND pp.persn id - u.user id 
AND u.login name = "ВТ0016" 
union select 0 as org skid 
from sys.dual) org 
) 
and T1792779.bus unit skid ІМ (0,11769,11772,11774,11777,11779,11780,14329,14334,1433 
9,14340,14341,14350,14800,14801) 
and T1796547.bus unit skid IN (0,11769,11772,11774,11777,11779,11780,14329,14334,1433 
9,14340,14341,14350,14800,14801) 
and T1796263.bus unit skid IN (0,11769,11772,11774,11777,11779,11780,14329,14334,1433 
9,14340,14341,14350,14800,14801) 
and T1796631.bus unit skid IN (0,11769,11772,11774,11777,11779,11780,14329,14334,1433 
9, 14340, 14341, 14350,14800,14801) 





and (case when T1796631.CORP PRMTN TYPE CODE = 'Target Account' then 'Corporate' 
else T1796631.CORP PRMTN TYPE CODE end іп ('Corporate', 'Planned', 'Private')) 
and T1796631.PRMTN LONG NAME in (select distinct T1796631.PRMTN LONG NAME as cl 
from 

ОРТ ACCT ЕРІМ T1792779 /* ОРТ ACCT PRMTN ЕРІМ */ , 

OPT BUS UNIT FDIM T1796263, 

OPT | CAL | | MASTR - DIM T1796564 /% ОРТ CAL MASTR DIMOl */ , 
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ОРТ PRMTN FDIM T1796631, 

OPT PRMTN | PROD FLTR LKP T1796906 

where ( T1792779. ACCT SKID = T1796906.ACCT PRMTN SKID 

and T1792779.BUS UNIT SKID - T1796906.BUS _UNIT | SKID 

and T1796263.BUS UNIT SKID T1796906.BUS _UNIT | SKID 

and 71796564.CAL | MASTR SKID = T1796906.DATE _SKID 

and T1796631.PRMTN . SKID = T1796906.PRMTN | SKID 

and T1792779.ACCT LONG МАМЕ = 'EN- -AEON GROUP (JUSCOJ4) (C005) - 1900001326' 
and T1796263.BUS UNIT NAME - 'Japan' and T1796564.FISC YR ABBR NAME - 'FY10/11' 
and T1796631.BUS UNIT SKID - T1796906.BUS UNIT SKID 

and (case when T1796631.CORP PRMTN TYPE CODE - 'Target Account' then 'Corporate' els 
e T1796631.CORP PRMTN TYPE CODE end іп ('Corporate', 'Planned', 
'Private')) and ROWNUM >= 1) ) ) 

group by T1792779.NAME, T1792779.CHANL TYPE DESC, 

T1792779.ACCT LONG NAME, T1796631. PRMTN | SKID, 

T1796631. PRMTN ID, T1796631.PRMTN МАМЕ, 

T1796631.SHPMT END DATE, T1796631. .SHPMT START DATE, 

T1796631.PRMTN STTUS CODE, T1796631.APPRV STTUS CODE, 
T1796631.CMMNT DESC, T1796631.PGM START DATE, 

T1796631.PGM END DATE, T1796631. CREAT DATE, 

T1796631.APPRV BY DESC, T1796631.AUTO UPDT GTIN IND, 

T1796631.PRMTN STOP DATE, T1796631.ACTVY DETL POP, 

T1796631.CNBLN ИК СМТ, T1796631.PRMTN АУС РОР, 

case when case 

when T1796631.CORP PRMTN TYPE CODE - 'Target Account' 

then 'Corporate' else T1796631.CORP PRMTN TYPE CODE end is null 

then 'Private' else case when 

T1796631.CORP PRMTN TYPE CODE - 'Target Account' then 'Corporate' 

else T1796631.CORP PRMTN TYPE CODE end end , nvl(case when 
T1796631.PRMTN STTUS CODE - 'Confirmed' 


then cast(( TRUNC( ТО РАТЕ ('2011-04-26' ; 'YYYY-MM-DD') ) - TRUNC( T1796631.PGM END D 
ATE ) ) as VARCHAR ( 10 ) ) 
end , * wv) 


order by c23, c2; 


执行 缓慢 的 SQL 与 执行 较 快 的 SQL 相 比 , 缓慢 的 SQL 在 where 条 件 中 多 了 以 下 部 分 代码 。 


-- add RLS 
and T1796547.acct skid IN (select  org.org skid from (SELECT DISTINCT ap.org skid 
FROM opt acct postn lkp ap, opt party persn lkp pp, opt user lkp u 
WHERE ap.postn id - pp.party id 
AND pp.persn id u.user id 
AND u.login name = 'BT0016"' 
union select 0 as org skid 
from sys.dual) org 
) 
and T1792779.bus unit skid IN (0,11769,11772,11774,11777,11779,11780,14329,14334,1433 
9,14340,14341,14350,14800,14801) 
and T1796547.bus unit skid IN (0,11769,11772,11774,11777,11779,11780,14329,14334,1433 
9,14340,14341,14350,14800,14801) 
and T1796263.bus unit skid IN (0,11769,11772,11774,11777,11779,11780,14329,14334,1433 
9,14340,14341,14350,14800,14801) 
and T1796631.bus unit skid IN (0,11769,11772,11774,11777,11779,11780,14329,14334,1433 
9,14340,14341,14350,14800,14801) 
-- end RLS 


这 部 分 代码 就 是 实现 Row Level Security 功能 的 代码 ， 对 于 权限 较 低 的 账户 过 滤 掉 一 部 分 
数据 ， 而 对 于 权限 最 高 的 账号 不 做 过 滤 。 如 果 不 加 RLS 代码 ， 报 表 能 在 16 秒 内 执行 完毕 ， 但 
是 增加 了 RLS 代码 ， 报 表 执 行 了 15 分 钟 不 出 结果 。 通 过 以 上 信息 ， 我 们 判断 是 由 于 增加 了 
RLS 代码 ， 导 致 执行 计划 发 生 了 变化 ， 从 而 导致 SQL 性 能 问题 。 
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RLS 代码 中 有 一 个 in 子 查 询 ，in 子 查 询 中 有 union 关键 字 。 在 第 7 章 中 讲 到 过 子 查询 非 
ЕСЕ, 5 where 条 件 中 有 子 查询 ， 优 化 器 会 尝试 将 子 查询 展开 ， 从 而 消除 Filter. in 子 查询 中 
有 union 是 可 以 展开 的 (unnest)， 而 exists 子 查询 中 有 union 是 不 可 以 展开 的 。 如 果 where 条 
件 中 的 子 查 询 不 能 展开 (no_unnest)， 执 行 计划 中 会 出 现 Filter, Filter 一 般 是 在 SQL 的 最 后 阶 
段 执 行 。 如 果 where 条 件 中 的 子 查 询 展开 了 ， 子 查询 会 与 主 表 提 前 关联 。 

因为 增加 了 RLS 代码 导致 SQL 产生 了 性 能 问题 ，RLS 代码 中 有 in 子 查询 ， 因 为 in 子 查 
询 可 以 展开 〈unnest)， 所 以 我 们 推断 是 优化 器 的 子 查询 非 嵌 套 (Subquery Unnesting〉 导 致 产 
生 的 性 能 问题 , 让 Obiee 开发 人 员 在 in 子 查询 中 添加 HINT: МО UNNEST, 让 子 查询 不 展开 。 
子 查询 不 展开 ， 执 行 计 划 中 就 会 出 现 Filter， 但 是 Filter 是 在 最 后 进行 过 滤 ， 子 查询 不 展开 就 
不 会 干扰 原始 的 〈 跑 得 快 的 ) 执行 计划 ， 只 是 在 跑 得 快 的 执行 计划 的 最 后 一 步 添加 Filter 过 滤 
而 已 。 添 加 完 HINT 之 后 ，SQL 能 在 12 秒 内 执行 完毕 。 

因为 子 查 询 中 有 union， 这 里 也 可 以 不 添加 HINT: NO UNNEST, 将 in 改写 为 exists， 这 
时 优化 器 会 自动 走 Filter， 也 能 达到 优化 目的 。 需 要 提醒 大 家 的 是 ， 千 万 不 要 因为 我 们 将 in ck 
写 为 exists、exists 执行 快 就 说 exists 性 能 比 让 高。 如 果 有 谁 遇 到 本 案例 ， 将 in 改写 为 exists; 
然后 发 布 博客 说 今天 又 用 exists 优化 了 in 子 查询 ， 这 只 会 让 人 贻 笑 大 方 。 

罗 老 师 的 个 人 技术 博客 中 还 记录 了 另 一 个 RLS 引发 的 性 能 问题 ， 大 家 如 有 兴趣 也 可 以 查 






2011 年 ， 一 位 朋友 请 求 优化 如 下 SQL。 
select tpc.policy id, 
tcm.policy code, 
tpf.organ id, 
to char(tpf.insert time, 'YYYY-MM-DD') As insert time, 
tpc.change id, 
d.policy code, 
e.company name, 
f.real name, 
tpf.fee type, 
sum(tpf.pay balance) as pay balance, 
c.actual type, 
tpc.notice code, 
d.policy type, 
g.mode name as pay mode 
from t policy change tpc, 


t contract master tcm, 
t policy fee tpf, 
t fee type a 


t customer 4. NA 
t pay mode g 
where tpc.change id - tpf.change id 
and tpf.policy id - d.policy id 
and tcm.policy id - tpc.policy id 


and tpf.receiv status = 1 
and tpf.fee status = 1 
and tpf.payment id is null 
and tpf.fee type - c.type id 
and tpf.pay mode - g.mode id 
апа d.company id = e.company id(+) 
апа d.applicant id = f.customer id(*) 
and tpf.organ id in 
(select 
organ id 
from t company organ 
start with organ id - '101' 
connect by prior organ id - parent id) 
group by tpc.policy id, 


tpc.change i 


d, 


tpf.fee type, 


to char (tpf. 


insert time, 'YYYY-MM-DD'), 


c.actual type, 
d.policy code, 


g.mode name, 


e.company name, 


f.real name, 


tpc.notice code, 
d.policy type, 
tpf.organ id, 
tcm.policy code 
order by change id, fee type; 


执行 计划 如 下 。 


SQL» select * from table(dbms xplan.display); 


PLAN TABLE OUTPUT 


| 
| 1| SORT GROUP BY | 
|* 2| HASH JOIN | 
| 3| INDEX FULL SCAN |T FEE TYPE IDX 003 
| 4|  NESTED LOOPS OUTER | 
|* 5| HASH JOIN | 
16 NESTED LOOPS | 
I* 7) HASH JOIN SEMI | 
1% 8] HASH JOIN OUTER | 
[*.9] HASH JOIN | 
1*101 HASH JOIN | 
1111 TABLE ACCESS FULL |T PAY MODE 
|*12| TABLE ACCESS FULL |Т POLICY FEE 
| 251 TABLE ACCESS FULL |T CONTRACT MASTER 
1141 VIEW lindex join 007 
|*15| HASH JOIN | 
| 16| INDEX FAST FULL SCAN |PK T CUSTOMER 
| 17| INDEX FAST FULL SCAN |IDK CUSTOMER ВІК REAL GEN 
| 18| VIEW [УИ NSO 1 
1*19| СОММЕСТ BY WITH FILTERING | 
| 20| NESTED LOOPS | 
|*21| INDEX UNIQUE SCAN ІРК T COMPANY ORGAN 
| 22| TABLE ACCESS BY USER ROWID|T COMPANY ORGAN 
| 23| NESTED LOOPS | 
| 24| BUFFER SORT | 
| 25| CONNECT BY PUMP | 
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145962| 11М| 
145962| 11M| 
|45962| 11М| 
| 106| 636| 
|45962| 11М 
145962|7271К| 


145961 | 6283K| 
|45961 |5655К| 


| 400K| 
| 400K| 
| 400К| 
1 #291 
| 400K| 
|1136K| 





45M 
39MI 
23M 
525| 
15М| 
46М 
30M| 
45M 
30M 


70| 


23M 


6824K 


145650 


45650 
43908 
1 
43906 
43905 
42312 
33120 
32315 
26943 
16111 
2 
16107 
9437 


32315 
548 
548 


(0) | 
(0) | 
(0) | 
(0) | 
(0) | 
(0) | 
(0) | 
(1) | 
(1) | 
(0) | 
(0) | 
(0) | 
(0) | 
(0) | 

| 
(1)! 
(0) | 
(0) | 
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мәннынс 2 


|5261 INDEX RANGE SCAN |Т COMPANY ORGAN IDX 002 | 7| 701 | 1 (0) 
| 271 TABLE ACCESS BY INDEX ROWID |T POLICY CHANGE I Tid edil | 2 (50)| 
|*28| INDEX UNIQUE SCAN |PK T POLICY CHANGE | 1| | | y. ¿(Oy 
| 29] INDEX FAST FULL SCAN (ІШКІ ACCEPT DATE |1136K| 23MI | 899 (0)| 
| 30| TABLE ACCESS BY INDEX ROWID |Т COMPANY CUSTOMER | 1| 901 | 2 (50)| 
1*31] INDEX UNIQUE SCAN [PK T COMPANY CUSTOMER | 1| | | | 


2. = access("TPE","FEE TYPE"-"C".""TYPE ID") 
S - access("TCM"." POLICY ID"—"TPC",."POLICY ID") 
7 = ассевв("ТРЕ"."ОВСАМ ID"-"VW NSO 1"."$nso col 1") 
8 — access("D"."APPLICANT ID"-"F"."CUSTOMER ID"(*)) 

= access("TPE" "POLICY XD"-"D"."POLICY 1р") 

10 — access("TPF"."PAY MODE"-"G",."MODE ID") 

12 - filter("TPF"."CHANGE ID" IS NOT NULL AND TOUNUMBER(UTPE"I"RECEIV STATUS")ST AN 
D "TPF"."FEE STATUS"-1 AND 

"ТРЕ", "РАҮМЕМТ ID" IS NULL) 


15 access("indexjoin alias 012".ROWID-"indexjoin alias 011".ROWID) 
19 filter("T COMPANY ORGAN"."ORGAN | Ір"-"101!) 
21 access ("Т COMPANY ORGAN" "ORGAN | Ір"='т01%) 


28 access("TPC"."CHANGE Ір"="ТРЕ"."СНАМСЕ Ір") 


26 = access ("Т ' COMPANY ОСАМ". "РАВЕМТ ID"-NULL) 
31 — access("D"."COMPANY ID"-"E",."COMPANY Ір" (+)) 


55 rows selected 


Statisties 


VIS S Бы? 
125082 consistent gets 
21149 physical reads 
бы. С н aot via SQL*Net to client 
656 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
4 sorts (memory) 
0 sorts (disk) 
11 rows processed 
Ex SQL 要 执行 12 Ж, ЖНЖ 12 2. iZ SQL Б, t policy fee tpf 400 7717, 
t contract master tcm 有 1000 万 行 。 其 余 表 都 是 小 表 。 
根据 SQL 三 段 分 拆 方法 首先 检查 了 SQL 写法 ，SQL 写法 没有 明显 不 妥 之 处 。 然 后 开始 检 
查 执行 计划 。 我 们 注意 观察 执行 计划 的 统计 信息 (Statistics), 该 SQL 最 终 只 返回 11 行 数据 (11 
rows processed)。SQL 中 有 13 个 GROUP BY 字段 ， 一 般 而 言 ，GROUP BY 字段 越 少 ， 去 重 
能 力 越 强 ; GROUP BY 字段 越 多 ， 去 重 能 力 越 弱 。 因 此 ， 我 们 判断 该 SOL 在 GROUP BY 之 
前 只 返回 少量 数据 ， di roc ZEREA, 而 不 是 走 HASH 连接 。 既然 推断 出 该 SQL 
最 终 返 回 数据 量 较 少 ， 那 么 SQL 中 的 大 表 都 应 该 走 索引 ， 但 是 SQL 语句 中 的 两 个 大 表 
t policy fee tpf 与 (OR eism tcm 都 是 走 的 全 表 扫 描 ， 这 显然 不 对 。 它 们 应 该 走 索 引 , 或 
者 作为 嵌 套 循环 的 被 驱动 表 。 
根据 上 面 分 析 ， 我 们 将 注意 力 集中 在 了 大 表 (14-12 和 Id=13) 上 ， 同 时 也 将 注意 力 集中 
在 了 HASH 连接 上 。 执 行 计 划 中 14-12 有 TO_NUMBER("TPF"."RECEIV_STATUS")=1， 开 发 
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人 员 少 写 了 引号 , 这 可 能 导致 SQL 不 走 索 引 。Id=13 前 面 没有 “*” 号 ,这 说 明 T_ CONTRACT 
MASTER 没有 过 滤 条 件 ， 如 果 走 HASH 连接 ， 那 么 该 表 只 能 走 全 表 扫 描 。 但 是 该 表 有 1000 
万 条 数据 ， 所 以 只 能 让 它 作 为 嵌 套 循环 被 驱动 表 ， 然 后 走 连 接 列 的 索引 。 
SQL 语句 中 有 个 in 子 查询 ， 并 且 子 查询 中 有 固化 子 查询 关键 字 start with, E 7.1 节 中 讲 
到 ，in 子 查询 中 有 固化 子 查询 关键 字 ， 子 查询 可 以 展开 (unnest)。 这 个 їп 子 查询 只 返回 1 行 
数据 ,在 执行 计划 中 它 属 于 Id=18， 然 后 它 与 Id=8 进行 的 是 HASH 连接 。Where 子 查 询 unnest 
之 后 ， 一 般 都 会 打 乱 执 行 计 划 ， 也 就 是 说 Id-8, 14-9, Id-10, Id-11, 14-12, 14-13, 14-14 
的 执行 计划 都 会 因为 子 查询 被 展开 而 在 一 起 关联 的 。 
我 们 再 回去 看 原始 SQL, Min SQL 中 只 有 tpf 表 有 过 滤 条 件 ， 其 他 表 均 无 过 滤 条 件 。 而 
tpf 表 的 过 滤 条 件 要 么 是 状态 字段 过 滤 (tpf.receiv_status = 1 and tpf.fee_status = 1), 要 么 是 组 织 
编号 过 滤 tpf.organ_id in〈( 子 查询 )。 因 此 判断 这 些 过滤 条 件 并 不 能 过 滤 掉 大 部 分 数据 。SQL 中 
有 两 处 外 链接 ，d.company id = е.сотрапу id(+)，d.applicant id = f.customer_id(+), WREEK 
套 循环 ， 外 连接 无 法 更 改 了 驱动 表 。 如 果 走 HASH 连接 ， 外 连接 可 以 更 改 驱动 表 。 
因为 SQL 最 终 只 返回 少量 数据 ， 我 们 判断 执行 计划 应 该 走 骨 套 循环 。 走 姑 套 循环 首先 要 
确定 好 谁 做 驱动 表 。 根 据 上 面 的 分 析 ef 首先 被 排除 掉 做 驱动 表 的 可 能 性 ， 因 为 它们 是 外 连接 
的 从 表 ，tpf，tcm 也 被 排除 掉 作 为 驱动 表 的 可 能 性 ， 因 为 它们 是 大 表 。 现 在 只 剩 下 tpc，c #l g 
可 以 作为 驱动 表 候 选 ，tpc，c,g 都 是 与 tpf 关联 的 ， 只 需要 看 谁 最 小 ， 谁 就 作为 驱动 表 。 而 在 
原始 执行 计划 中 ， 因 为 in 子 查询 被 展开 了 ， 扰 乱 了 执行 计划 ， 导致 It=11，Id=12，Id=13 走 了 
HASH 连接 ， 所 以 笔者 对 子 查询 添加 了 HINT: NO_UNNEST， 让 子 查询 不 展开 ， 从 而 不 去 干 
扰 执 行 计划 ， 添 加 HINT 后 的 SQL 如 下 。 
select tpc.policy id, 
tcm.policy code, 
tpf.organ id, 
to char(tpf.insert time, 'YYYY-MM-DD') As insert time, 
tpc.change id, 
d.policy code, 
e.company name, 
f.real name, 
tpf.fee type, 
sum(tpf.pay balance) as pay balance, 
c.actual type, 
tpc.notice code, 


d.policy type, 
ghe name as pay mode 


from t policy change tpc, 
3 .contract master tcm, 
t policy fee tpf, 


t fee type с, 

t contract master d, 

t company customer e, 

t customer É; 

t_pay_mode g 

where tpc.change_id = tpf.change_id 

and tpf.policy_id = d.policy_id 
and tcm. DR іа рс. „policy id 
and ЁрЁ.: tatu. к= "1 -=- 这 里 原来 没 引号 ， 是 开发 搞 忘 了 写 '， 
and tpf. fee | "totos s = 1 
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and tpf.payment_id is null 
and tpf.fee_type = c T: 
and tpf.pay_mode = g.mode_id 
and d.company_id = e.company_id(+) 
and d.applicant_id = f.customer_id(+) 
and tpf.organ id in 
(select / 
organ id 
from t company organ 
start with organ іа = '101' 
connect by prior organ id - parent id) 
group by tpc.policy id, 
tpc.change id, 
tpf.fee type, 
to char(tpf.insert time, 'YYYY-MM-DD'), 
c.actual type, 
d.policy code, 
g.mode name, 
e.company name, 
f.real name, 
tpc.notice code, 
d.policy type, 
tpf.organ id, 
tcm.policy code 
order by change id, fee type 


执行 计划 如 下 。 


SQL» select * from table(dbms xplan.display); 





PLAN TABLE OUTPUT 























| Id|Operation | Name |Rows |Bytes| Cost ($CPU)| 
| O|SELECT STATEMENT | |20026|4928K| 68615 (30) | 
| 1| SORT GROUP BY | [20026|4928K| 28563 (0) 
|* 2| FILTER | 
3| NESTED LOOPS 120026|4928К| 27812 (0) 
4 NESTED ТООР5 |20026 |4498К| 23807 (0) 
5 NESTED LOOPS OUTER |20026|4224K| 19802 (0) 
6 NESTED LOOPS OUTER 120026|3911К| 15797 (0) 
қ; NESTED LOOPS |20026|2151K| 15796 (0) 
* 8 HASH JOIN |20026|1310К| 11791 (0) 
9 INDEX FULL SCAN T FEE TYPE IDX 003 106| 636 1 (0) 
*10 HASH JOIN 20026|1192K| 11789 (0) 
11. TABLE ACCESS FULL T PAY MODE 25 525 2 (0) | 
*12 TABLE ACCESS BY INDEX ROWIDIT POLICY ЕЕЕ 20026| 782K| 11786 (0) | 
| *13] INDEX RANGE SCAN |IDX POLICY FEE RECEIV STATUS |1243K| 10188 (0) | 
14| TABLE ACCESS BY INDEX ROWID |Т CONTRACT MASTER 1| 43 2 (50)| 
RISI INDEX UNIQUE SCAN IPK T CONTRACT MASTER 1| 1 (0) 
16| TABLE ACCESS BY INDEX ROWID |Т COMPANY CUSTOMER 11 90 2 (50) | 
[*171 INDEX UNIQUE SCAN |PK T COMPANY CUSTOMER 1| 
| 18| TABLE ACCESS BY INDEX ROWID |T CUSTOMER 1 16 2 (50) 
IS] INDEX UNIQUE SCAN IPK T CUSTOMER 1 1 (0) 
| 20| TABLE ACCESS BY INDEX ROWID |T POLICY CHANGE 1 14 2 (50) 
|*21| INDEX UNIQUE SCAN |PK T POLICY CHANGE 1 1. (0) 
1-223 TABLE ACCESS BY INDEX ROWID |T CONTRACT MASTER 1 22 2 (50) 
1*23| INDEX UNIQUE SCAN \РК T CONTRACT MASTER 1 | i. (0) 
|*24| FILTER | 
[*25] CONNECT BY WITH FILTERING 
| 26| NESTED LOOPS | | 
1*27| INDEX UNIQUE SCAN |PK T COMPANY ORGAN 1 6| 
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TABLE ACCESS BY USER ROWID |T COMPANY ORGAN | | | | 
NESTED LOOPS | | | | | 
BUFFER SORT | een 74 70) | 
CONNECT BY PUMP | | | | | 
INDEX RANGE SCAN |T COMPANY ORGAN IDX 002 | 7| | 70| tox 0) 


- filter( EXISTS (SELECT /%% NO UNNEST */ 0 FROM "T COMPANY ORGAN" "T COMPANY OR 
WHERE 
"T COMPANY ORGAN"."PARENT ID"-NULL AND ("T COMPANY ORGAN"."ORGAN ID"-:B 


= access("SYS ALIAS Т". "ЕЕЕ ТҮРЕ"="С". "ТҮРЕ ID") 
- access ("SYS "ALIAS 1"."PAY _MODE"= nG", "MODE ` О") 
= filter("SYS ALIAS 1"."CHANGE ID" IS NOT NULL AND "SYS ALIAS 1"."FEE STATUS"-1 





"SYS ALIAS 1"."PAYMENT ID" IS NULL) 
- access("SYS ALIAS 1"."RECEIV STATUS"-']') 
- access ("SYS "ALIAS | POLICY ID"-2"p","POLICY ID") 
~ access("D". "COMPANY | ID"-"E","COMPANY ID" (+) ) 
- access("D"."APPLICANT ID"-"F","CUSTOMER : ID"(4)) 
- access("TPC"."CHANGE ID"-"SYS | ALIAS 1". "CHANGE _ ID") 
= access("TCM", "POLICY ID"z"TpC", "POLICY ID") 
- filter("T COMPANY  ORGAN"."ORGAN Ір"=:ВІ) 
- filter("T COMPANY ORGAN"."ORGAN ID"-'101') 
- access ("Т COMPANY ORGAN"."ORGAN ID"-'101') 
- access("T COMPANY ORGAN"."PARENT ID"-NULL) 


58 rows selected. 


Statistics 


0 recursive calls 
0 db block gets 
2817 consistent gets 
0 physical reads 
0 redo size 
2268 bytes sent via SQL*Net to client 
656 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
40 sorts (memory) 
0 sorts (disk) 
9 rows processed 


添加 完 HINT 之 后 ,SQL 能 在 1 秒 内 执行 完毕 , 逻辑 读 也 降低 到 2 817。 如 果 不 想 添 加 HINT, 
我 们 可 以 将 in 改 成 exists， 因 为 子 查询 中 有 固化 子 查询 关键 字 ， 这 时 SQL 不 能 展开 ， 会 自动 走 
Filter， 也 能 达到 添加 HINT: NO UNNEST 的 效果 ， 但 是 ， 这 并 不 是 说 exists 比 in 性 能 好 ! 

我 们 推荐 大 家 在 Oracle 中 使 用 in 而 不 是 使 用 exists。 因 为 exists 子 查 询 中 有 固化 子 查 询 关 
键 字 会 自动 走 Filter， 想 要 消除 Filter 只 能 改写 SQL. in 可 以 控制 走 Filter 或 者 不 走 ，in 执行 计 


划 可 控 ， 


而 exists 执行 计划 不 可 控 。 


对 于 їп 子 查询 ， 我 们 一 定 要 搞 清楚 in 子 查询 返回 多 少数 据 ， 究 竟 能 起 到 多 大 过 滤 作用 。 
Ж in 子 查询 能 过 滤 掉 主 表 大 量 数据 ， 这 时 我 们 一 定 要 让 in 子 查询 展开 并 且 作 为 NL 驱动 表 
反 向 驱动 主 表 ， 主 表 作 为 NL 被 驱动 表 ， 走 连接 列 索引 。 如 果 in 子 查询 不 能 过 滤 掉 主 表 大 量 
数据 ， 这 时 要 检查 in 子 查询 返回 数据 量 多 少 ， 如 果 返 回 数据 量 很 少 ，in 子 查询 即使 不 展开 ， 
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Ж Filter 也 不 大 会 影响 SQL 性 能 。 如 果 in 子 查询 返回 数据 量 很 多 ， 但 是 并 不 能 过 滤 掉 主 表 大 
量 数据 ， 这 时 一 定 要 让 in 子 查询 展开 并 且 与 主 表 走 HASH 连接。 

本 案例 中 ,in 子 查 询 返 回 数据 量 很 少 ， 只 有 1 行 数据 , 但 是 主 表 并 不 能 用 子 查询 过 滤 大 量 
数据 ， 因 为 过 滤 条 件 是 tpf.organ id， 组织 关系 id 这 种 列 一 般 基数 很 低 。 其 实 原始 SQL 相当 于 
如 下 写法 。 


select tpc.policy id, 
tcm.policy code, 
tpf.organ id, 
to char(tpf.insert time, 'YYYY-MM-DD') As insert time, 
tpc.change id, 
d.policy code, 
e.company name, 
f.real name, 
tpf.fee type, 
sum(tpf.pay balance) as pay balance, 
c.actual type, 
tpc.notice code, 
d.policy type, 
g.mode name as pay mode 


from t policy change tpc, 
t contract master tcm, 
t policy fee tpf, 
t fee type c, 


t contract master а, 

t company customer e, 

t customer LS 

t pay mode g 

where tpc.change id tpf.change id 

and tpf.policy id d.policy id 
and tcm.policy id tpc.policy id 
and tpf.receiv status = 1 
and tpf.fee status - 1l 
and tpf.payment id is null 


and tpf.fee type = c.type id 
and tpf.pay mode - g.mode id 
d.company id = e.company іа (+) 






d nt id f.customer id 
3 (xat) --—MER 
group by tpc.policy id, | 
tpc.change_id, 
tpf.fee type, 
to char(tpf.insert time, 'YYYY-MM-DD'), 
.actual type, 
.policy code, 
.mode name, 
.company name, 
.real name, 
tpc.notice code, 
d.policy type, 
tpf.organ id, 
tcm.policy code 
order by change id, fee type; 


因为 原始 SQL 本 意 相 当 于 以 上 SQL, 子 查询 只 起 过 滤 作用 ,所 以 使 用 HINTNO_UNNEST， 
让 子 查 询 不 去 干扰 正常 执行 计划 ， 从 而 达到 优化 目的 。 






+ 


тоа о. о 
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本 案例 与 上 一 个 案例 是 同一 个 人 的 优化 请 求 ，SQL 语句 如 下 。 


select distinct decode(length(a.category id), 
5, 
decode(a.origin type, 801, 888888, 999999), 
a.category id) category id, 
a.notice code, 
a.treat status, 
lr.real name as receiver name, 
f.send code, 
f.policy code, 
g.real name agent name, 
f.organ id, 
f.dept id, 
a.policy id, 
a.change id, 
a.case id, 
a.group policy id, 
a.fee id, 
a.auth id, 
a.pay id, 
cancel appoint.appoint time cancel appoint time, 
a.insert time, 
a.send time, 
a.end time, 
f.agency code, 
a.REPLY TIME, 
a.REPLY EMP ID, 
a.FIRST DUTY, 
a.NEED SEND PRINT, 


11 source 
from t policy problem a, 
t policy T, 
t agent g, 
t letter receiver lr, 
t problem category рс; 


t policy cancel appoint cancel appoint 
where f.agent id = g.agent id(*) 
and a.policy id - f.policy id(*) 
and lr.main receiver - 'Y' 
and a.category id - pc.category id 
and a.item id - lr.item id 
and a.policy id = cancel appoint.policy id(+) 







and a.policy id is nu 
and a.notice code is not null 

and a.change id is null 

and a.case id is null 

and a.group policy id is null 

and a.origin type not in (801, 802) 

and a.pay id is null 

and a.category id not in (130103, 130104, 130102, 140102, 140101) 

and f.policy type = '1' 

and (a.fee id is null or (a.fee id is not null and a.origin type - 701)) 
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and pc.NEED PRITN = 'Y'; 


朋友 说 这 个 SQL 执行 不 出 结果 。 执 行 计划 如 下 。 


PLAN TABLE OUTPUT 





|SELECT STATEMENT 
| SORT UNIQUE 
| 





NESTED LOOPS OUTER 
NESTED LOOPS 
NESTED LOOPS OUTER 
NESTED LOOPS 
TABLE ACCESS FULL 


INDEX UNIQUE SCAN 


INDEX UNIQUE SCAN 

| TABLE ACCESS BY INDEX ROWID 
| INDEX UNIQUE SCAN 

TABLE ACCESS BY INDEX ROWID 
| INDEX UNIQUE SCAN 

| INDEX RANGE SCAN 





TABLE ACCESS BY INDEX ROWID 
INDEX RANGE SCAN 








CONNECT BY WITH FILTERING 
NESTED LOOPS 

INDEX UNIQUE SCAN 

TABLE ACCESS BY USER ROWID 
HASH JOIN 

CONNECT BY PUMP 

TABLE ACCESS FULL 


| 

| 

| 

| 

| 

| 

| 

| CONNECT BY WITH FILTERING 
| NESTED LOOPS 

| INDEX UNIQUE SCAN 

| TABLE ACCESS BY USER ROWID 
| NESTED LOOPS 

| BUFFER SORT 

| CONNECT BY PUMP 

| INDEX RANGE SCAN 


|T POLICY PROBLEM 


TABLE ACCESS BY INDEX ROWID|T POLICY 


|PK T POLICY 


TABLE ACCESS BY INDEX ROWID|T POLICY CANCEL APPOINT 


|UK1 POLICY CANCEL APPOINT 
|T PROBLEM CATEGORY 

|PK T PROBLEM CATEGORY 

|T AGENT 

|PK T AGENT 

|T LETTER RECEIVER IDX 001 
| 

|T POLICY PROBLEM 

|IDX POLICY PROBLEM М CODE 
| 

| 

| 

IPK T DEPT 

|T DEPT 

| 

| 

|Т DEPT 

| 

| 

| 

IPK T COMPANY ORGAN 

|T COMPANY ORGAN 

| 

| 

| 

|T COMPANY ORGAN IDX 002 


w № 


56 
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8 - 


9.24 ЗЕМИ 






filter("SYS ALIAS 1"."POLICY ID" IS NOT NULL AND "SYS ALIAS 1"."NOTICE CODE" I 


S NOT NULL AND 


"SYS ALIAS 1"."CHANGE ID" IS NULL AND "SYS ALIAS 1"."САЗЕ ID" IS NULL AND 
"SYS ALIAS 1"."GROUP POLICY ID" IS NULL AND TO NUMBER("SYS ALIAS 1"."OR 


ІСІМ ТҮРЕ")<>801 AND 


TO NUMBER("SYS ALIAS 1"."ОВІСІМ ТҮРЕ")<>802 AND "SYS ALIAS 1"."PAY ID" 


IS NULL AND 

"SYS ALIAS 1"."САТЕСОВҮ 10"<>130103 AND "SYS ALIAS 1"."CATEGORY Ір"<>13 
0104 AND 

"SYS ALIAS 1"."CATEGORY 10"<>130102 AND "SYS ALIAS 1"."CATEGORY ID"<>14 
0102 AND 

"SYS ALIAS 1"."CATEGORY ID"<>140101 AND ("SYS ALIAS 1"."FEE ID" IS NULL 
OR 


"SYS ALIAS 1"."FEE ID" IS NOT NULL AND TO NUMBER("SYS ALIAS 1"."ORIGIN 


TYPE") -701)) 


9 = 
10 - 
12 - 
18 ~ 
14 - 


filter(TO NUMBER("SYS ALIAS 3"."POLICY TYPE")-1) 

access("SYS ALIAS 1". "POLICY ID"-"SYS ALIAS 3"."POLICY ID") 

access("SYS , "ALIAS ` dms "POLICY ID"-"CANCEL ‚ APPOINT"."POLICY PDP CE) Y 

filter("PG". "NEED PRITN"-'Y') 

access("SYS ALIAS 1"."CATEGORY Ір"="РС"."САТЕСОВҮ ID") 

filter("PC"."CATEGORY 10"<>130103 AND "PC"."CATEGORY ID"<>130104 AND "PC"."CAT 


EGORY 10"<>130102 


AND "PC"."CATEGORY 1р"<>140102 AND "PC","CATEGORY ID"«»140101) 
access("SYS ALIAS 3"."AGENT ID"-"G"."AGENT Ір" (+)) 
access("LR"."MAIN RECEIVER"-'Y' AND "SYS ALIAS 1"."ITEM ID"-"LR"."ITEM ID") 
access("T POLICY PROBLEM". "NOTICE СОрЕ"=:В1) 
filter ("T БЕРТ". "DEPT - ID"=:B1) 
filter("T DEPT". "DEPT ID"-'1020200028"') 
access("T DEPT"."DEPT ID"-'1020200028') 
filter("T COMPANY ORGAN"."ORGAN ID"-:Bl) 
filter("T COMPANY ORGAN"."ORGAN ID"-'10202") 
access ("Т COMPANY ORGAN"."ORGAN ID"-'10202') 
access("T COMPANY ORGAN"."PARENT ID"-NULL) 


77 rows selected. 


从 执行 


J 计划 中 14-2 看 到 ， 该 SQL Ж Т Filter，Id=3、Id=18、Id=21、Id=29 都 是 Id=2 的 儿 


To KX Filter ИОА, WR Id=3 返回 大 量 数据 ， 会 导致 It=18、Id=21、Id=29 被 多 次 
扫描 ， 正 是 因为 SQL 走 的 是 Filter， 才 导致 SQL 执行 不 出 结果 。 

为 什么 会 走 Filter W? 我 们 注意 查看 SQL 写法 ，SQL 语句 中 有 两 个 exists (TEW), T 
查询 中 有 固化 子 查询 关键 字 start with， 正 是 因为 SQL 写成 了 exists， 才 导致 走 了 Filter. TÆ 
我 们 用 in 改写 exists。 


select 


distinct decode(length(a.category id), 

5, 
decode(a.origin type, 801, 888888, 999999), 
a.category id) category id, 

a.notice code, 

a.treat status, 

lr.real name as receiver name, 

f.send code, 

f.policy code, 

g.real name agent name, 


249 








f.organ_id, 

f.dept id, 
a.policy id, 
a.change id, 
a.case id, 

a.group policy id, 
a.fee id, 

a.auth id, 

a.pay id, 

cancel appoint.appoint time cancel appoint time, 
a.insert time, 
a.send time, 

a.end time, 
f.agency code, 
a.REPLY TIME, 
a.REPLY EMP ID, 
a.FIRST DUTY, 
a.NEED SEND PRINT, 
11 source 


from t policy problem a, 
t policy f, 
t agent g, 
t letter receiver lr, 
t problem category pc, 


t policy cancel appoint cancel appoint 

where f.agent іа = g.agent id(*) 

and a.policy id = f.policy id(*) 

and lr.main receiver = "'Y' 

and a.category id - pc.category id 

and a.item id = lr.item id 

and a.policy іа = cancel appoint.policy іа(+) 

And a.Item Id - (Select Max(item id) 

From t Policy Problem 
Where notice code - a.notice code) 

and a.policy id is not null 

and a.notice code is not null 

and a.change id is null 

and a.case id is null 


and a.group policy id is null 
and a.origin type not in (801, 802) 
and a.pay id is null 
and a.category id not in (130103, 130104, 130102, 140102, 140101) 
and f.policy type - '1' 
( 


a.fee id is null or (a.fee id is not null and a.origin type - 701)) 











and pc.NEED PRITN - 'Y'; 


改写 后 的 执行 计划 如 下 。 


| IdlOperation | Name |Rows |Bytes|Cost (%СРО) | 
| O|SELECT STATEMENT | | 1| 259| 742 (1)| 
| 1| SORT UNIQUE | | 1| 259] 740 (0)| 
|* 2| ETER | | | | | 
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|* 3| HSA JOIN || 259| 725 (1) 
| 741 NESTED LOOPS iaasa RI I) 
ШАШ NESTED LOOPS 23 ji 236 #28 (5 
| 6) NESTED LOOPS OUTER 1 229 TeL (1) 
jm NESTED LOOPS OUTER zs. 7207 (1) 
|* 8 HASH JOIN 11 229 719 (L) 
| 9 NESTED LOOPS 1| 182| 662 (1) 
| *10 TABLE ACCESS FULL T POLICY PROBLEM 1 107 660 (0) 
ІЗІ TABLE ACCESS BY INDEX ROWID|T POLICY £ 15 2 (50) 
*12 INDEX UNIQUE SCAN PK T POLICY 1 сө) 
13| VIEW VW NSO 1 30601| 508K 
|*14 CONNECT BY WITH FILTERING 
15 NESTED LOOPS 
1*16 INDEX UNIQUE SCAN IPK T DEPT 11 d Y €) 
| 17 TABLE ACCESS BY USER ROWID|T DEPT 
V T8 HASH JOIN 
19 CONNECT BY PUMP 
20 TABLE ACCESS FULL T_DEPT 30601| 896K 56 (0) 
| 21 TABLE ACCESS BY INDEX ROWID |T AGENT Т 16 2 (80) 
*22 INDEX UNIQUE SCAN |PK T AGENT 11 
23 TABLE ACCESS BY INDEX ROWID |T POLICY CANCEL APPOINT 1 14 2 (50) 
|*24 INDEX UNIQUE SCAN UK1_POLICY CANCEL APPOINT T 
*25 TABLE ACCESS BY INDEX ROWID T PROBLEM CATEGORY 1 7 2 (50) 
1%26 INDEX UNIQUE 5САМ PK T PROBLEM CATEGORY 1 
*27| INDEX RANGE SCAN T LETTER RECEIVER IDX 001 1 17 2 (0) 
28| VIEW [УЙ NSO 2 7 42 
|*29 CONNECT BY WITH FILTERING 
| 30 NESTED LOOPS | 
*31 INDEX UNIQUE SCAN PK T COMPANY ORGAN d 6 
32] TABLE ACCESS BY USER ROWID T COMPANY ORGAN 
33 NESTED LOOPS 
34 BUFFER SORT i 70 
|285 CONNECT BY PUMP 
|*36 INDEX RANGE SCAN T COMPANY ORGAN IDX 002 7 70 1 (0) 
37 SORT AG 1 21 
38 TABLE ACCESS BY INDEX ROWID T POLICY PROBLEM 3, zr 2 (50) 
*39 INDEX RANGE SCAN IDX POLICY PROBLEM N CODE 1| SaO 





СОрЕ"=:В1)) 
3 = access("F"."ORGAN ID"-"VW NSO 2". "$пзо col 1") 
8 = access("F"."DEPT ID"-"VW NSO 1"."$nso col 1") 
10 - filter("SYS ALIAS 1"."POLICY ID" IS NOT NULL AND "SYS ALIAS 1"."NOTICE CODE" I 
S NOT NULL AND 
"SYS ALIAS 1"."CHANGE ID" IS NULL AND "SYS ALIAS 1"."CASE ID" IS NULL AND 
"SYS ALIAS 1"."GROUP POLICY ID" 
15 NULL AND TO NUMBER("SYS ALIAS 1"."ORIGIN ТҮРЕ")<>801 AND 
TO NUMBER("SYS ALIAS 1"."ORIGIN ТҮРЕ") <>802 
AND "SYS ALIAS 1"."PAY ID" IS NULL AND "SYS ALIAS 1"."CATEGORY Ір"<>13 





0103 AND 

"SYS ALIAS 1"."CATEGORY TD"<>130104 AND "SYS ALIAS 1"."CATEGORY ID"<>13 
0102 AND 

"SYS ALIAS 1"."CATEGORY 10"<>140102 AND "SYS ALIAS 1"."CATEGORY ID"«»14 
0101 AND 


("SYS ALIAS 1"."FEE ID" IS NULL OR "SYS ALIAS 1"."FEE ID" IS NOT NULL AND 
TO NUMBER("SYS ALIAS 1"."ORIGIN TYPE")-701)) 
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11 = filter("F"."POLICY TYPE"-'1!) 

12 - access("SYS ALIAS 1"."POLICY ID"-"F"."POLICY ID") 

14 = filter("T DEPT",."DEPT ID"-'1020200028') 

16 - access("T DEPT"."DEPT ID"-'1020200028') 

22 - access("F"."AGENT ID"-"G"."AGENT ID" (+)) 

24 - access("SYS ALIAS 1"."POLICY ID"-"CANCEL APPOINT"."POLICY ID"(*)) 
25 - filter("PC"."NEED PRITN"-'Y') 

26 - access("SYS ALIAS 1l"."CATEGORY Ір"-"РС"."САТЕСОВҮ ID") 


filter("PC"."CATEGORY 10"<>130103 AND "PC"."CATEGORY Ір"<>130104 AND "PC"."CAT 
EGORY 10"<>130102 


AND "PC"."CATEGORY 10"<>140102 AND "PC"."CATEGORY 1р"<>140101) 


27 - access("LR"."MAIN RECEIVER"-'Y' AND "SYS ALIAS 1"."ITEM ID"-"LR"."ITEM ID") 
29 - filter("T COMPANY ORGAN"."ORGAN ID"-'10202') 

31 - access("T COMPANY ORGAN"."ORGAN ID"-'10202') 

36 - access("T COMPANY ORGAN"."PARENT ID"-NULL) 

39 - access("T POLICY PROBLEM"."NOTICE СОрЕ"=:В1) 


SQL 改写 之 后 ， 可 以 在 35 秒 左 右 出 结果 ， 而 之 前 是 很 久 跑 不 出 结果 。 用 in 代替 exists 之 
后 ， 两 个 in 子 查询 因为 进行 了 Subquery Unnesting， 消 除了 Filter。 从 执行 计划 中 我 们 可 以 看 
到 , 两 个 子 查 询 都 走 的 是 HASH 连接 , 这 样 两 个 in 子 查询 都 只 会 被 扫描 一 次 。 用 in 代替 exists 
之 后 ， 执 行 计划 中 还 有 Filter， 这 时 的 Filter 来 自 于 t_Policy_Problem 自 关 联 。 


And a.Item Id = (Select Max(item id) 
From t Policy Problem 
Where notice code - a.notice code) 


在 第 8 章 中 讲 到 ， 可 以 利用 分 析 函 数 改 写 自 关 联 。 因 为 当时 朋友 对 35 秒 出 结果 已 经 很 满 
意 ， 所 以 我 们 没有 进一步 改写 SQL。 本 以 为 能 逃 过 帮忙 改写 SQL “— J”, 但 是 2012 年 刚 过 
完 春 节 , 就 被 朋友 骚扰 了 , 朋友 要 求 继续 优化 , 有 兴趣 的 读者 可 以 查看 博客 : http://blog.csdn.net/ 
robinson1988/article/details/7219958 。 

通过 阅读 本 案例 , 相信 大 家 应 该 纠正 了 exists 效率 比 in 高 这 种 错误 认识 。 如果 where 子 查 
询 中 没有 固化 子 查 询 关 键 字 ， 不 管 写成 in 还 是 写成 exists， 效 率 都 是 一 样 的 ， 因 为 CBO 始终 
能 将 子 查询 展开 (unnest)。 如 果 where 子 查 询 中 有 固化 子 查询 关键 字 ， 这 时 我 们 最 好 用 іп 而 
不 是 exists, AX in 可 以 控制 子 查询 是 否 展开 ， 而 exists 无 法 展开 。 至 于 where 子 查询 是 展开 
性 能 好 还 是 不 展开 性 能 好 ， 我 们 要 具体 情况 具体 分 析 。 


F) 烂 用 外 连接 导致 无 法 谓词 推 


2015 年 ， 一 位 甲骨 文公 司 的 朋友 请 求 协助 优化 。 有 个 SQL 单 次 执行 需要 26.57 秒 ， 一 共 
要 执行 226 次 ， 如 图 9-12 所 示 。 


SQL ordered by Elapsed Time 


„ Resources reported for PL/SQL code includes the resources used by all SOL statements called by the code. 
• % Total DB Time is the Elapsed Time of the SOL statement divided into the Tota! Database Time multiplied by 100 
• "Total - Elapsed Time as a percentage of Total DB tme 

CPU - CPU Time as a percentage of Elapsed Time 
* %IO - User V/O Time as a percentage of Elapsed Time 
* Captured SOL account for 42 5% of Total DB Time (6) 55,134 
» Captured PL/SQL account for 4,3% of Total DB Time (s) 55,134 
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SQL 代码 如 下 。 


SELECT view xj ct.ybjshj FROM view xj ct 
WHERE view xj се.бЕ сойбе = :1 AND view xj сі.БКЄОЕр = :2 


view xj ct 是 一 个 视图 ， 视 图 定义 如 下 。 


CREATE OR REPLACE FORCE VIEW "JXNC"."VIEW XJ CT" ("CT CODE", "PK CT MANAGE", "YBJSHJ" 
„ "ТЕНИ", "KPUE", "JE", "PK CORP") AS 
select 8 "бТТЕОВЕН, 
а."РК СТ МАМАСЕ", 
a."YBJSHJ", 
a."FKHJ", 
b.kpje, 
(case 
when b.kpje >= a.ybjshj then 


pkcorp —— 
from (select GEh.ct code; 
cth.pk ct manage, 
sum(ctb.oritaxsummny) ybjshj, 
sum(ctv.ljfk) fkhj, 


c 





from 
left 30 
on ctb.pk ct manage - cth.pk ct manage 
left join view xj ct fukuan ctv 
on ctv.pk ct manage b - ctb.pk ct manage b 
and ctv.pk ct manage - cth.pk ct manage 
where activeflag = 0 
and cth.dr - 0 
and ctb.dr - 0 
group by cth.ct code, cth.pk ct manage, ctb.pk corp) a 
left join (select cth.pk ct manage, sum(fp.noriginalsummny) kpje 
from po invoice b fp 
left join po order b dd 
on fp.csourcebillrowid - dd.corder bid 
left join ct manage b ct 
on ct.pk ct manage b - dd.csourcerowid 
left join ct manage cth 
on ct.pk ct manage - cth.pk ct manage 
where fp.dr = 0 
апа dd.cupsourcebilltype = 'z2' 
group by cth.pk ct manage) b 
on b.pk ct manage - a.pk ct manage; 


代码 中 : 表 ct manage b 有 数据 266 274 (26 万 条 记录 ), K сі manage 有 数据 88 563 (8.8 
万 条 记录 )， 表 po invoice b 有 数据 294 467 (29 万 条 记录 )， 表 ро order b 有 数据 143122 (14 
万 条 记录 )。 

上 面 视图 view xj ct 中 又 内 骸 一 个 视图 view xj ct fokuan， 视 图 代码 如 下 。 


CREATE OR REPLACE FORCE VIEW "JXNC"."VIEW XJ CT FUKUAN" ("DDHH", "PK CORP", "PK CT MA 
NAGE B", "PK CT MANAGE", "LJFK", "CT CODE") AS Е š 
select ddhh, 
a.pk_corp, 
a.pk ct manage b, 
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ctb.pk ct manage, 
sum(a.ljfk) 1jfk, 
eth.et, code 
from (select a.ddhh, 
a.dwbm pk_corp, 
a.zyx5 pk ct manage b, 
a.jfybje ljfk 
from arap djfb a 
left join arap djzb b on a.vouchid - b.vouchid 
where a.dr - 0 


and b.dr = 0 

and a.djlxbm = 'D3' 

and a.jsfsbm in ('Z2', 'Z5',"pi1') 
and Буаз с not іп ('-991. TT'YY а 


left join ct manage b ctb on ctb.pk ct manage b - a.pk ct manage b 

left join ct manage cth on cth.pk ct manage - ctb.pk ct manage 
group by ddhh, a.pk corp, a.pk ct manage b, ctb.pk ct manage, cth.ct code 
order by a.pk ct manage b; 


其 中 : Ж агар djfo 有 数据 1175 707 (117 万 条 记录 )， 表 агар djzb 有 数据 149 157 (15 
万 条 记录 )， 表 ct manage b 有 数据 266 274 (26 万 条 记录 )， 表 ct manage 有 数据 88 563 (8.8 
万 条 记录 )。 

SQL 语句 的 执行 计划 如 下 。 


SOL» explain plan for SELECT view xj ct.ybjshj FROM view xj ct 
2 WHERE view xj ct.ct code = :1 AND view xj ct.pk corp = :2; 


Explained. 
SQL» select * from table(dbms xplan.display); 
PLAN TABLE OUTPUT 


Plan hash value: 3563589558 





























Id|Operation Name |Rows |Bytes|TempSpc | Cost ($CPU) | Time 
O|SELECT STATEMENT 1 57 49994 (1)|00:10:00| 
* 1| HASH JOIN OUTER 1 87 49994 (1) |00:10:00 
2| VIEW nA 35 |32190 (1) |00:06:27 
3| HASH GROUP BY 1 74 32190 (1) 100:06:27 
wal HASH JOIN OUTER i|. $4 32189  (1)|00:06:27| 
5 VIEW i 35| 2 (0) 100:00:01 
ЖГ NESTED LOOPS 
7| NESTED LOOPS | 1 95 2 (0) 100:00:01 
* 8| TABLE ACCESS BY INDEX ROWID |СТ MANAGE | 1 40 1 (0) 100:00:01 
* 9 INDEX RANGE SCAN ІІСЕМ1 | 2 1 (0)|00:00:01| 
%10 INDEX RANGE SCAN ICTMBZ1 3 1 (0)/00:00:01 
Тт TABLE ACCESS BY INDEX ROWID CT MANAGE B ih 55 1 £(0)/00:00:01 
12 VIEW VIEW XJ CT FUKUAN |39191|1492K 32186 (1) |00:06:27 
13 HASH GROUP BY 39191|6468K| 6976К|32186 (1)|00:06:27| 
|*14 HASH JOIN RIGHT OUTER 39191|6468K| 3976К|30726 (1) |00:06:09 
15 TABLE ACCESS FULL CT MANAGE 88505|2938К| 1621 (2) |00:00:20 
*16 HASH JOIN OUTER 39191|5166K| 4024К|28636 (1) |00:05:44 
%17 HASH JOIN ,. | 39191|3559K| 2952К|23574  (1)|00:04:43 
18 INLIST ITERATOR | 
*19 TABLE ACCESS BY INDEX ROWID|ARAP DJFB 39191|2487K| 20692 (1)|00:04:09 
*20 INDEX RANGE SCAN I АВАР DJFB 252С02| 337K 251 (2) |00:00:04 
21, TABLE ACCESS FULL ARAP DJZB 127K|3476K 2494  (2)|00:00:30 
22 TABLE ACCESS FULL CT MANAGE B 266K| 10M 4179  (2)|00:00:51 
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VIEW 


HASH GROUP BY 
HASH JOIN 
TABLE ACCESS FULL 
HASH JOIN RIGHT OUTER 
INDEX FAST FULL SCAN 
HASH JOIN OUTER 
TABLE ACCESS FULL 


|PO INVOICE B 
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188480 |1900К| 


|88480| 10М| 
| 120K| 14М| 
| 138К|3389К| 
|98165| 9М| 


|88505|1815К| 
|98165 |8052К| 
|98165 |4026К| 
| 266К| 10М| 


117802 
16М|17802 
5024К|14906 
| 5263 
2856К| 8850 
| 107 
5184K| 8154 
| 3035 

| 4179 


词 推 入 


(1) |00:03:34| 
(1) 100:03:34| 
(1) |00:02:59| 
(1) 100:01:04| 
(2) |00:01:47| 
(2) 100:00:02| 
(2) |00:01:38| 
(1) |00:00:37| 
(2) |00:00:51| 


1 - access("B"."PK CT MANAGE" (+)= 
4 = access("CTV"."PK CT MANAGE" (+)="CTH". "PK CT MANAGE" AND 
"CTV"."PK | . CT MANAGE B" (+) = 
8 - filter("CTH"."DR"-0 AND "CTH"."ACTIVEFLAG"- 


9 - access("CTH"."CT CODE"-:1) 
- access("CTB"."PK CT MANAGE"-"CTH"."PK CT MANAGE") 


10 


filter("CTB". "PK | CORP"-:2 AND "CTB"."DR"- 0) 
access ("CTH". "PK | CT MANAGE" (+) = 
access ("CTB". "PK CT MANAGE B"(*)- 


"A"."PK CT MANAGE") 


access ("A". "VOUCHID"-"B", "VOUCHID") 


filter("A"."DJLXBM"-'D3' AND "A"."DR"-0) 
"AU"."ISFSBM"-'72' 


access ("A",."JSFSBM"-'D1' 


OR 


z"CTB". "PK Ст _МАМАСЕ В") 
0) 


"CTB"."PK CT MANAGE") 
"д", "ZYX5") 


OR "A"."JSFSBM"-'Z5') 


filter("B"."DR"-0 AND "B"."DJZT"«»1 AND "B"."DJZT"«»5(-99)) 
access ("FP"."CSOURCEBILLROWID"-"DD"."CORDER BID") 


filter("FP" 
access ("CT". 
access ("CT" 
filter("DD". 


60 rows selected. 


对 于 上 述 的 执行 计划 ， 


骨 文 公司 的 朋友 创建 了 一 个 index. 


create index idx jszc1026 on ARAP djfb(jsfsbm,djlxbm,dr); 


之 前 大 约 26 秒 出 结果 , 创建 新 index 后 速度 是 2.6 秒 出 结果 , 新 建 索引 后 的 执行 计划 如 下 。 


PLAN TABLE OUTPUT 


Plan hash value: 


2820245905 


."CSOURCEBILLROWID" IS NOT NULL AND "FP"."DR"-0) 
"PK CT MANAGE"-"CTH"."PK CT MANAGE" (+)) 
."PK | CT MANAGE B" (+)="DD". "CSOURCEROWID") 
"CUPSOURCEBILLTYPE"-' Z2!) 


| OJSELECT STATEMENT 
|* 1| HASH JOIN OUTER 
VIEW 


L 21 
| 31 
p] 
| 5) 
| 6l 
Т 
І% 8| 
1% 9| 
|*10| 
18111 
| 121 
| 131 
1*14| 


TABLE ACCESS BY INDEX ROWID 
INDEX RANGE SCAN 
INDEX RANGE SCAN 
TABLE ACCESS BY INDEX ROWID 
VIEW 
HASH GROUP BY 
HASH JOIN RIGHT OUTER 


то acd 





Д Б 
1 $7] 
11) — 39i 
1| 74 
Ap 74 
l| “357 
| | 
Tp 95] 
1|  40| 
2| | 
3l | 
i[ Бі 
39191|1492K| 


39191|6468K] 
39191 | 6468K| 


|14234 
6976К |14234 
3976К|12775 


(1) 100:06:25| 
(1) 100:06:25| 
(2) |00:02:51| 
(2) 100:02:51| 
(2) |00:02:51| 
(0) 100:00:01| 

| | 
(0) |00:00:01 | 
(0) |00:00:01| 
(0) |00:00:01 | 
(0) |00:00:01| 
(0) |00:00:01 | 
(2) 00:02:51] 
(2)100:02:51] 
(2)100:02:34] 
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| 351 TABLE ACCESS FULL ICT MANAGE 88505|2938K| | 1621 (2)/00:00:20| 
|*16| HASH JOIN OUTER | 39191|5166K| 4024К|10685  (2)|00:02:09| 
8121 HASH JOIN | |39191|3559K| 2952K| 5622 (1)100:01:08| 
| 18| INLIST ITERATOR | | | | | | | 
1 19] TABLE ACCESS BY INDEX ROWID|ARAP DJFB 139191 |2487K| | 2740 (1)1|00:00:331| 
|*20| INDEX RANGE SCAN |IDX JSZC1026 39212| | | 43 (3)]00:00:01| 
1%21| TABLE ACCESS FULL IARAP DJZB 127K|3476K| | 2494 (2) |00:00:30| 
| 22| TABLE ACCESS FULL |CT MANAGE B 266K| 10М| | 4179 (2) 100:00:51| 
| 23| VIEW | 88480|1900K| |17802 (1)1|00:03:34| 
| 24] HASH GROUP BY | 88480| 10М| 16М|17802 (1)|00:03:34| 
|*25| HASH JOIN | | 120K| 14M| 5024К|14906 (1) 100:02:59] 
1*26| TABLE ACCESS FULL |PO INVOICE B | 138К|3389К| | 5263 (1)|00:01:04| 
1*27| HASH JOIN RIGHT OUTER | 198165| 9М| 2856К| 8850 (2)|00:01:47| 
| 28| INDEX FAST FULL 5САМ IPK CT MANAGE 88505|1815К| | 107 (2) |00:00:02| 
|%29| HASH JOIN OUTER | 198165|8052K| 5184К| 8154 (2)100:01:38| 
1*30| TABLE ACCESS FULL | PO. ORDER В 198165 |4026к| | 3035 (1) 100:00:371 
| 311 TABLE ACCESS FULL [CT MANAGE В | 266K| 10М| | 4179  (2)/00:00:51] 


1 一 access("B"."PK CT МАМАСЕ"(%)-"А"."РК CT MANAGE") 
4 — access("CTV". "PK | CT MANAGE" (+) ="СТН". "PK | CT MANAGE" AND 
"Оту, "PK | CT MANAGE В" (+) ="СТВ". "РК. Ст | MANAGE В") 
8 - filter("CTH"."DR"- 0 ^ AND "СТН". "ACTIVEFLAG"-0) 
9 - access("CTH"."CT CODE"-:1) 
10 = access("CTB"."PK i eT MANAGE"-"CTH". "PK CT MANAGE") 
IL — fiiter("CTB^? "PK | CORP"-:2 AND "CTB" ."DR"=0) 
14 — access("CTH". "PK | CT MANAGE" (+) ="СТВ"."РК CT MANAGE") 
16 = access("CTB"."PK | CT MANAGE В" (+) ="А". "ZYX5") 
17 - access ("A"."VOUCHID"-"B", "VOUCHID") 
20 - access(("A"."JSFSBM"-'D1' OR "A","JSFSBM"-'22' OR "A",."JSFSBM"-'25') AND "A"," 
DJLXBM"-'D3' AND 
"д" = " DR"-0) 
21 - filter("B"."DR"-0 AND "B"."DJZT"«»1 AND "B"."DJZT"«»(-99)) 
25 - access("FP"."CSOURCEBILLROWID"-"DD"."CORDER BID") 
26 - filter("FP"."CSOURCEBILLROWID" IS NOT NULL AND "FP","DR"-0) 
27 - access("CT"."PK CT MANAGE"-"CTH"."PK CT MANAGE" (+)) 
29 = access ("Chi "PK | CT MANAGE В" (+) ="DD" . "CSOURCEROWID") 
30 - filter("DD"."CUPSOURCEBILLTYPE"='Z2') 





60 rows selected. 


如 图 9-13 所 示 ， 做 一 笔 单据 在 后 台 要 多 次 调用 这 个 语句 。 











pen w | КЕ, | 读 职 记录 数 Í DEFER 
2312 8 282005711 
2625 1 282005711 
de 2547 1 282005711 
SELECT view. x| ctybjshi FROM vi... 执行 完毕 2531 1 282005711 
SELECT view, xj. ctybjsh] FROM vi... 执行 完毕 2547 1 282005711 
SELECT view_xj_ctybjsh| FROM vi... 执行 完毕 2500 1 282005711 
CT view. xj ctybjsh| FROM М... 执行 完毕 2531 1 282005711 
SELECT view xj ct ybjshj FROM vi... 执行 完毕 2594 1 282005711 
SELECT view. x, ctybish] FROM vi... 执行 完毕 2578 1 282005711 
SELECT view. xi ctybjshi FROM vi... 执行 完毕 2516 1 282005711 
SELECT view. xi. c ybish| FROM vi... 执行 完毕 2546 1 282005711 
SELECT view xj ctyb|sh| FROM vi... 执行 元 毕 2516 282005711 
SFIFFPTView vi rivhishi FRIMW Зітті 7581 п - ж + 282006734 
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100 个 SQL 语句 每 个 执行 2.6 秒 ， 全 部 执行 就 要 260 秒 ， 将 近 4 分 钟 。 到 这 里 ， 甲 骨 文 的 
朋友 问 能 和 否 进一步 优化 该 SQL。 

下 面 是 分 析 过 程 。 

在 尝试 优化 SQL 之 前 ， 首 先 询问 该 SQL 返回 多 少 行 数据 ， 甲 骨 文 的 朋友 回答 返回 1 行 数 
据 。 在 进行 SQL 优化 的 时 候 ， 我 们 必须 知道 一 个 SQL 最 终 应 该 返回 多 少 行 数 据 ， 因 为 知道 了 
SQL 最 终 返 回 数据 ， 就 能 判断 表 连 接 究竟 是 采用 髓 套 循 环 还 是 采用 HASH 连接 ， 这 至 关 重 要 。 
因为 SQL 最 终 返 回 一 行 数据 ， 所 以 判断 SQL 的 执行 计划 应 该 走 髓 套 循 环 。 但 是 本 SQL 执行 
计划 中 几乎 全 是 HASH 连接 。 根 据 SQL 语句 过 滤 条 件 入 手 ， 一 步 一 步 分 析 执 行 计 划 ， 看 哪里 
出 了 问题 。 

SQL 语句 的 过 滤 条 件 是 WHERE view xj ct.ct code = :1 AND view xj ct.pk 
corp = :2ь 

这 两 个 过 滤 条 件 已 经 在 书 中 用 阴影 部 分 标注 ， 为 了 方便 读者 查看 现 将 其 摘抄 下 来 。 


select ЕВСЕН 
cth.pk ct manage, 


sum(ctb.oritaxsummny) ybjshj, 
sumictv.1jfk) fkhj, 





on ctb. pk ct manage = cth.pk ct manage 
left join view xj et ааа: (ЕУ 
on ctv.pk ct manage | S - ctb.pk ct manage b 
and ctv.pk ct manage - cth.pk ct manage 
where activeflag = 0 
and cth.dr = 0 
and ctb.dr = 0 
group by cth.ct code, cth.pk ct manage, ctb.pk corp 


过 滤 条 件 分 别针 对 cth 和 ctb 进行 过 滤 ， 执 行 计 划 中 14-9 走 的 是 cth.ct code 的 索引 ,这 说 
明 此 处 发 生 了 常量 谓词 推 入 , 将 过 滤 条 件 ( 常 量 过 滤 条 件 ) 推 入 到 视图 中 进行 了 过 滤 。Id=9 属于 
cth， 它 与 id=10(ctb) 走 的 是 嵌 套 循环 。cth 与 ctb 关联 的 结果 集 在 执行 计划 中 是 Id=5 这 步 , 14-5 
与 Id=12(view_xj_ct_fukuan) 进 行 的 是 HASH 连接 。Id=12 是 一 个 视图 。 因 为 该 SQL 最 终 只 返 
回 1 行 数 据 ， 应 该 全 走 髓 套 循 环 才 对 ， 但 是 关联 到 视图 view xj ct fukuan 的 时 候 居 然 走 的 是 
HASH 连接 , 所 以 笔者 判断 Id=5 与 Id=12 关联 方式 出 错 。 SQL 语句 中 , 视图 view xj ct fukuan 
的 别名 是 ctv, ctv 分 别 与 cth 和 ctb 进行 了 关联 。 


left join view xj ct fukuan ctv 
on BEVIBRUGE | manage] b = ctb.pk ct manage b 
and Gtv.pk. ct manage = cth.pk ct manage 


如 果 能 让 cth 与 ctb 关联 之 后 得 到 的 结果 集 通过 ctv 的 连接 列传 值 给 ctv， 通 过 连接 列 将 数 
据 将 数据 推 入 到 视图 中 ， 这样 就 可 以 让 视图 走 嵌 套 循环 了 ,这 种 方式 就 是 连接 列 谓词 推 入 , 但 
是 执行 计划 并 没有 这 样 做 。 

于 是 查看 如 下 视图 view xj ct fukuan 的 源 代码 。 
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CREATE OR REPLACE FORCE VIEW "JXNC"."VIEW XJ CT FUKUAN" ("DDHH", "PK CORP", "PK CT MA 
NAGE B", "PK CT MANAGE", "LJFK", "CT CODE") AS 
select ddhh, 
a.pk corp, 
a.pk ct manage b, 
сір.рк ct manage, 
sum(a.ljfk) 1jfk, 
cth.ct code 
from (select a.ddhh, 
a.dwbm pk corp, 
a.zyx5 pk ct manage b, 
a.jfybje ljfk 
from arap djfb a 
left join arap djzb b on a.vouchid - b.vouchid 
where a.dr = 0 
and b.dr = 0 
and a.djlxbm = 'D3' 
and a.jsfsbm in (*Z2', 'Z5','Dl') 
and b.djgt not in ('-99', '1!)j а 
left join ct manage b ЕВ on ctb.pk ct manage | 
left join ct manage cth on cth.pk ct manage = 
group by ddhh, a.pk corp, a.pk ct manage b, ctb.p 
order by a.pk ct manage b; 


视图 ctv.pk ct manage 字段 来 自 于 ctb, 而 ctb 与 a 是 外 连接 , 而且 ctb 是 从 表 , 并 不 是 主 表 。 
正 是 因为 ctb 是 视图 中 外 连接 的 从 表 ， 而 且 视 图 ctv 也 是 外 连接 的 从 表 ， 所 以 导致 cth 不 
E 通 过 连接 列 pk сі manage 将 谓词 推 入 到 ctv.pk ct manage 中 ， 从 而 导致 走 了 HASH 连接 。 


left join view_xj_ct_fukuan ctv 






ж a.pk ct 
а рК ch manaqa 


| ct manage, cth.ct code 








on gtv. pk ct manage B = ctb.pk ct manage b 
and G&tv.pk ctm Je = cth.pk ct manage 


如 果 能 将 视图 中 的 外 连接 改 成 内 连接 ， 就 可 以 将 谓词 推 入 到 ctv F, MATERE. 
通过 反复 分 析 SQL 写法 ， 我 们 确认 可 以 将 视图 中 的 外 连接 改写 为 内 连接 。 于 是 新 建 了 一 
个 视图 ， 专 门 用 于 本 SQL， 将 外 连接 改写 为 内 连接 ， 而 且 将 后 面 的 子 查询 也 改 成 了 内 连接 。 
最 终 SQL 能 在 0.01 秒 内 执行 完毕 ， 执 行 100 个 SQL 也 仅 需 耗 时 1 秒 ， 从 而 将 原本 要 执行 4 
分 钟 的 单据 业务 优化 到 1 秒 。 
接 下 来 ， 我 们 通过 实验 为 大 家 模拟 当时 情况 。 
SQL> create table emp new as select * from emp; 
Table created. 
SQL» create index idx ename on emp (ename) ; 


Index created. 


ME Ce) 里 面 表 关联 是 外 连接 ， 而 且 视图 Ce) 作为 外 连接 从 表 ， 视 图 〈e) 连接 列 来 自 
从 表 。 


select /*+ push pred(e) */ * 
from emp_new a Уһ 
Тег join (select d.dname, e.ename, sum(e.sal) total sal 
from dept d 
left join emp e on d.deptno = e.deptno 
group by dname, ename) e on a.ename - e.ename 


where empno = 7900; 


执行 计划 如 下 。 


SQL» select /*+ 


2 


3 
4 
5 
6 
7 
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push pred(e) */ * 
new à 
| (select d.dname, e.ename, sum(e.sal) total sal 


from dept d 
Defe join emp е on d.deptno = e.deptno 


group by dname, ename) e on a.ename - e.ename 








where empno 7900; 
Execution Plan 
Plan hash value: 3023292314 
Operation Name Rows Bytes Cost ($CPU)| Time 
SELECT STATEMENT 1 116 10  (30)] 0070001 
HASH JOIN ООТЕВ 1 116 10 (30)| 00:00:01 
TABLE ACCESS FULL EMP NEW d: 87 2 (0) 00:00:01 
VIEW 14 406 32 (29) 00:00:01 
HASH GROUP BY 14 364 7 (29) ] 00700201 
MERGE JOIN OUTER 14 364 6 (17)| 0020001 
TABLE ACCESS BY INDEX ROWID|DEPT 4 52 Ё (0)| 00:00:01 
INDEX FULL SCAN PK DEPT 4 1 (0) | 00:00:01 
SORT JOIN 14 | 182 4 (25)| 00:00:01 
TABLE ACCESS FULL EMP 14 182 3 (0) | 00:00:01 














- access("A", 


- filter("A" 


- access ("D". 


filter("D" 


"ENAME"-"E" Д "ENAME" (+) ) 
."ЕМРМО"-7900) 
"DEPTNO"-"E","DEPTNO" (*)) 
."DEPTNO"-"E","DEPTNO" (*)) 


当 视 图 里 面 表 关联 是 外 连接 , 而 且 视图 与 其 他 表 关 联 作为 外 连接 从 表 , 视图 连接 列 来 自视 
图 里 面 的 从 表 ， 此 时 不 能 谓词 推 入 。 
我 们 将 视图 里 面 表 关 联 改 成 内 连接 。 


select /*+ 


from emp new a 
T 7 dn am 


where empno - 7900; 








push pred(e) */ * 


n (select d.dname, e.ename, sum(e.sal) total sal 


from dept d 





ІП emp e on d.deptno = e.deptno 


group by dname, ename) e on a.ename = e.ename 


执行 计划 如 下 。 


SQL» select /*+ 


2 


3 
4 
Š 
6 
j 


push pred(e) */ * 


from emp new a 
left join (select d.dname, e.ename, sum(e.sal) total sal 


where empno 


from dept d 
join emp e on d.deptno - e.deptno 


group by dname, ename) e on a.ename - e.ename 


7900; 
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Execution Plan 


Plan hash value: 3258229530 























Id|Operation Name Rows Bytes Cost (СРО) | Time 
O|SELECT STATEMENT 3 ізі 6 4171) 00:00:01 
1| NESTED LOOPS OUTER 1 125, 6 (17) 00:00:01 
* 2 TABLE ACCESS FULL EMP NEW 1 87 2 (0) | 00:00:01 
ІЗ /1 ХЕЮІСАТЕ 1 24 4 (25) | 00:00:01 
) 4 SORT GROUP BY 1 26 4 (25у 00:00:01 
5 NESTED LOOPS 
6 NESTED LOOPS | Д 26 3 (0)| 00:00:01 
y TABLE ACCESS BY INDEZ ROWID | EMP | 1 T3 2 (0) 1 00:00:01 
* 8 INI б ENAM 1 1 (©). 00:00:01 
* 9 INDEX UNIQUE SCAN 3 0 (0) | 00:00:01 
10 TABLE ACCESS BY INDEX ROWID|DEPT 1 13 1 (0)] 00:00:01 














9 - access ("D"."DEPTNO"-"E" , "DEPTNO") 


将 视图 里 面 的 外 连接 改 成 内 连接 之 后 ， 我 们 就 可 以 将 谓词 推 入 到 视图 中 了 。 
如 果 不 改 视 图 中 的 外 连接 ， 将 SQL 语句 中 的 外 连接 改 成 内 连接 也 可 以 将 谓词 推 入 视图 。 


select /*+ push pred(e) */ * 
from emp new a 
П (select d.dname, e.ename, sum(e.sal) total sal 
from dept d 
emp e on d.deptno = e.deptno 











group by 


name, ename) e on a.ename = e.ename 
where empno - 7900; 
us S 
执行 计划 如 下 。 
SQL» select /x+ push pred(e) */ * 
2- from emp new a 


3 join (select d.dname, e.ename, sum(e.sal) total sal 

4 from dept d 

5 left join emp e on d.deptno - e.deptno 

6 group by dname, ename) e on a.ename - e.ename 
i where empno - 7900; 


Execution Plan 


Plan hash value: 3747089680 

















| Id|Operation Name Rows Bytes | Cost($CPU)| Time 

| O|SELECT STATEMENT T l2 Ñ 5 (20)| 00:00:01 

| 1| HASH GROUP BY 1 12594 5 (20)| 00:00:01 
1.2 NESTED LOOPS | | | 
ЕЗ NESTED LOOPS 1 125 | 4 (0)] 00:00:01 

| 4 NESTED LOOPS i 1121 3 (0) | 00:00:01 
pes TABLE ACCESS FULL EMP NEW 1 99: j 2 (0) | 00:00:01 

| 6 TABLE ACCESS BY INDEX ROWID|EMP 1 12 1] 1 (0)| 00:00:01 
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| INDEX RANGE SCAN |IDX ENAME| d 1 | 0 (0)1 00:00:01 
|% 81 INDEX UNIQUE 5САМ |PK DEPT | Е | | 0 (0)1 00:00:01 
| 3] TABLE ACCESS BY INDEX ROWID |DEPT | 1. | 13 | 1 (0) | 00:00:01 | 


5 = filter("A"."EMPNO"-7900) 
7 - access("A"."ENAME"-"E","ENAME") 
8 - access ("D"."DEPTNO"-"E" , "DEPTNO") 


笔者 当时 究竟 是 怎么 判断 可 以 将 view xj ct fukuan ctv 里 面 的 视图 改 成 内 连接 的 呢 ? 


请 大 家 注意 观察 原始 view xj ct 部 分 代码 。 


select cth.ct_code, 
cth.pk ct manage, 
sum(ctb.oritaxsummny) ybjshj, 
sum(ctv.ljfk) fkhj, 
ctb.pk corp 
from ct manage b ctb 
left join ct manage cth 
on ctb.pk ct manage - cth.pk ct manage 
left joi i сес pnk E 
on 
and 
where 
and 
and 
group by cth.ct code, cth.pk ct manage, ctb.pk corp 


注意 观察 阴影 部 分 连接 条 件 ， 视 图 ctv 中 的 连接 列 也 是 来 自 cth 和 ctb. 





CREATE OR REPLACE FORCE VIEW "JXNC"."VIEW XJ CT FUKUAN" ("DDHH", "PK CORP", 


NAGE B", "PK CT MANAGE", "LJFK", "CT CODE") AS 
select ddhh, 
a.pk corp, 
a.pk ct manage b, 
ctb.pk ct manage, 
sum(a.ljfk) ljfk, 
cth.ct code 
from (select a.ddhh, 
a.dwbm pk corp, 
a.zyx5 pk ct manage b, 
a.jfybje ljfk 
from arap djfb a 
left join arap djzb b on a.vouchid - b.vouchid 
where a.dr = 0 
and b.dr = 0 
and a.djlxbm = 'Dp3' 
and a.jsfsbm in ('22', '25','pi') 
and b.djzt not in ('999', "1туфта 
left join ct manage b ctb on 
left join ct manage cth on 
group by ddhh, a.pk corp, 
order by a.pk ct manage b; 


同时 视图 ctv 中 有 对 连接 列 进行 汇总 ， 这 其 实 相 当 于 如 下 SQL. 


select e.empno, sum(sum sal) 
from emp e 









| cth.ct code 


"PK CT MA 
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left join (select d.deptno, sum(sal) sum_sal 


mus dept d 
emp e on d.deptno = e.deptno 
(ӘерЕпб) d оп e.deptno = d.deptno 






9 sp 
group by empno; 


上 面 SQL 可 以 安全 地 将 left join 改写 为 inner join. 


select e.empno, sum(sum sal) 
from emp e 
left join (select d.deptno, sum(sal) sum sal 
from dept d 
emp e on d.deptno = e.deptno 
10) d on e.deptno = d.deptno 






group by епрпо; 


同 理 ， 原 始 SQL 中 后 面 的 子 查询 也 能 改写 为 inner join. 

想 要 优化 本 案例 中 的 SQL， 必 须 具 备 较 强 的 SQL 优化 能 力 以 及 较 强 的 SQL 改写 能 力 ， 这 
两 种 能 力 缺 一 不 可 。 通 过 本 案例 ,我 们 也 要 反思 ， 为 什么 开发 人 员 在 SQL 中 一 直 写 left join? 
我 们 甚至 怀疑 是 不 是 开发 人 员 只 会 left join, 或 者 不 管 写 什么 SQL. 一 直 left join, 这 太 可 怕 了 ， 
由 此 可 见 ， 在 系统 上 线 之 前 ，SQL 审核 是 多 么 重要 ! 


2011 年 ， 一 位 ITPUB 的 网 友 请 求 优化 如 下 SQL. 


SELEGT * 

FROM (SELECT А.ІМУОІСЕ ID, 

.VENDOR ID, 

.INVOICE NUM, 

.INVOICE AMOUNT, 

.GL DATE, 

.INVOICE CURRENCY CODE, 

SUM(NVL(B.PREPAY AMOUNT APPLIED, 0)) PAID AMOUNT, 
A.INVOICE AMOUNT - SUM (NVL (B. PREPAY AMOUNT APPLIED, 0)) REMAIN 
FROM ap.AP INVOICES ALL A, МАРР: 

WHERE А | | 
AND A.ORG_ID = 126 /*:B4*/ 
AND A.SOURCE = 'OSM IMPORTED' /*:B3*/ 

AND A.INVOICE NUM BETWEEN NVL( /*:B2*/ null, A.INVOICE NUM) AND 
NVL( /*:B1*/ null, A.INVOICE_NUM) 
GROUP BY A.INVOICE_ID, 
A.INVOICE NUM, 

A.INVOICE AMOUNT, 

A.VENDOR ID, 

A.GL DATE, 

A 

, 





р р p р > 






.INVOICE CURRENCY CODE) 
WHERE REMAIN > 0; 


iX SQL 要 执行 1 个 多 小 时 ，AP_UNAPPLY PREPAYS V 是 一 个 视图 ， 代 码 如 下 。 


CREATE OR REPLACE VIEW.APPS.AP UNAPPLY PREPAYS V AS 
SELECT AIDI1.ROWID ROW ID 





AID1.INVOICE DISTRIBUTION ID INVOICE DISTRIBUTION ID, 
AID1.PREPAY DISTRIBUTION ID PREPAY DISTRIBUTION ID, 


9.26 ”谓词 推 入 优化 案例 


AID1.DISTRIBUTION LINE NUMBER PREPAY DIST NUMBER, 

(-1) * AID1.AMOUNT PREPAY AMOUNT APPLIED, 
nvl(AID2.PREPAY AMOUNT REMAINING, AID2.AMOUNT) PREPAY.AMOUNT REMAINING, 
AIDI.DIST CODE COMBINATION ID DIST CODE COMBINATION ID, 
AIDI.ACCOUNTING DATE ACCOUNTING DATE, 
АІр1.РЕВІОЮ NAME PERIOD МАМЕ, 
AIDi.SET OF BOOKS ID SET OF BOOKS ID, 
AID1.DESCRIPTION DESCRIPTION, 
AIDl.PO DISTRIBUTION ID PO DISTRIBUTION ID, 
AIDi.RCV TRANSACTION ID ЕСУ TRANSACTION ID, 
AIDl.ORG ID ORG ID, 
AI.INVOICE NUM PREPAY NUMBER, 
AI.VENDOR ID VENDOR ID, 
AI.VENDOR SITE ID VENDOR SITE ID, 
ATC.TAX ID TAX ID, 
ATC.NAME TAX CODE, 
PH.SEGMENT1 PO NUMBER, 
PV.VENDOR NAME VENDOR NAME, 
PV.SEGMENT1 VENDOR NUMBER, 
PVS.VENDOR SITE CODE VENDOR SITE CODE, 
RSH.RECEIPT NUM RECEIPT NUMBER 

FROM AP INVOICES 





AP INVOICE DIS AI 
AP INVOICE еселе AID2, 
AP TAX CODES ATC, 
PO VENDORS PV, 
PO VENDOR SITES PVS, 
PO DISTRIBUTIONS PD, 
PO HEADERS PH, 
PO LINES PL, 
PO LINE LOCATIONS PLL, 
RCV TRANSACTIONS RTXNS, 
RCV SHIPMENT HEADERS RSH, 
RCV SHIPMENT LINES RSL 


WHERE AID1.PREPAY DISTRIBUTION ID = АІр2.ІМУОІСЕ DISTRIBUTION ID 
AND AI.INVOICE ID = AID2.INVOICE ID 
AND AID1.AMOUNT < 0 
AND nvl(AIDI.REVERSAL FLAG, 'N') != 'Y' 
AND АІр1.ТАХ CODE ID = ATC.TAX ID(+) 
AND AIDl.LINE TYPE LOOKUP CODE = 'PREPAY' 
AND AI.VENDOR ID = PV.VENDOR ID 
AND AI.VENDOR SITE ID = PVS.VENDOR SITE ID 
AND АІр1.РО DISTRIBUTION ID = PD.PO DISTRIBUTION ID(*) 
AND PD.PO HEADER ID = PH.PO HEADER ID(+) 
AND PD.LINE LOCATION ID = PLL.LINE LOCATION ID(*) 
AND PLL.PO LINE ID = PL.PO LINE ID(*) 
AND AID1.RCV TRANSACTION ID = RTXNS.TRANSACTION ID(*) 
AND RTXNS.SHIPMENT LINE ID = RSL.SHIPMENT LINE Ір(%) 
AND RSL.SHIPMENT HEADER ID = RSH.SHIPMENT HEADER ID(*); 


执行 计划 如 下 。 

| Id |Орегағіоп | Name |Rows |Bytes|Cost | 
| 0 |SELECT STATEMENT | | 1l 69| 722| 
|* 1 | FILTER | | | | | 
| 2 | SORT GROUP BY | | Th 26915722] 
>. NESTED LOOPS OUTER | | 3| 207| 697| 
ж 471 TABLE ACCESS FULL |AP INVOICES ALL | 3| 153] 694| 
1: 5) V [CATE |AP UNAPPLY PREPAYS V | 1| 18| 1| 
Б) | | T 73721 3| 
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|545) NESTED LOOPS | | 1| 368| 3I 
| 8! NESTED LOOPS | | 1| 3611 2| 
| I NESTED LOOPS | | 1| 2471 11 
1101 NESTED LOOPS OUTER | | 1| 334| 1| 
EEEN NESTED LOOPS OUTER | | Lb 311 Al 
(aai NESTED LOOPS OUTER | | 1| 295| 11 
21381 NESTED LOOPS OUTER | | 1] 269| 1| 
| 14 | NESTED LOOPS OUTER | | 11 2433 1| 
WES NESTED LOOPS OUTER | | 1| 197| 1 
16:71 NESTED LOOPS OUTER | | ¿U 2971 1| 
ШЫ! NESTED LOOPS OUTER | | 1| 98| 1| 
[38 | | 11% 721 11 
119 | FULL 4 | 1| | | 
|*20 | TABLE ACCESS BY INDEX ROWIDIAP ' TAX CODES ALL | 1| 26| | 
*21 1 INDEX UNIQUE SCAN |AP TAX | CODES | | Ul | 1] | | 
[*22 | TABLE ACCESS BY INDEX ROWIDIPO DISTRIBUTIONS ALL l 11 59| І 
1%23 | INDEX UNIQUE SCAN |PO DISTRIBUTIONS ! | UI | ¿I I 

|*24 | TABLE ACCESS BY INDEX ROWID |PO HEADERS ALL | 1| 40| | 
[*25 | INDEX UNIQUE SCAN |PO HEADERS Ul | 11 | | 
1*26 | TABLE ACCESS BY INDEX ROWID |PO LINE LOCATIONS ALL | 1| 46| | 
|*27 | INDEX UNIQUE SCAN IPO LINE LOCATIONS Ul | 1| І І 
|%28 | TABLE ACCESS BY INDEX ROWID |PO LINES ALL | 1| 26| 

1*29 | INDEX UNIQUE SCAN IPO LINES ! | Ul | 1! І | 
| 30 | TABLE ACCESS BY INDEX ROWID [ВСУ ' TRANSACTIONS | 1 26| | 
I*3Y 1 INDEX UNIQUE SCAN |RCV TRANSACTIONS 01 | 1| | | 
1-32. ] TABLE ACCESS BY INDEX ROWID |RCV SHIPMENT | LINES | 1] 26| | 
[#33 | INDEX UNIQUE SCAN [АСУ : SHIPMENT | LINES | Ul | 1| | | 
1*34 | INDEX UNIQUE SCAN ЕСУ. SHIPMENT | HEADERS 1 Ul | 1| 223] | 
[*35 | TABLE ACCESS BY INDEX ROWID |AP INVOICE | DISTRIBUTIONS } ALL | 1⁄1 131 

I*36 | INDEX UNIQUE SCAN |AP i INVOICE | DISTRIBUTIONS | | U2 | 11 | | 
[*39 | TABLE ACCESS BY INDEX ROWID |AP INVOICES ALL | 1l 14| 1| 
1%38 | INDEX UNIQUE SCAN |AP INVOICES Ul | 11 | | 
|*39 | TABLE ACCESS BY INDEX ROWID ІРО” VENDOR : SITES j ALL | 1 71 11 
|*40 | INDEX UNIQUE SCAN ІРО” VENDOR : SITES | Ui | 1| | | 
|*41 | INDEX UNIQUE SCAN |PO VENDORS Ul | 1| 4j | 


1 - filter("A"."INVOICE AMOUNT"-SUM(NVL("B"."PREPAY AMOUNT APPLIED",0))20) 
4 - filter("A"."ORG ID"-126 AND "A"."SOURCE"-'OSM IMPORTED' AND 
"А","ІМУОІСЕ NUM"2-NVL(NULL,"A"."INVOICE NUM") AND "А", "ІМУОІСЕ NUM"«-N 


VL(NULL,"A"."INVOICE NUM")) 






AND 
"AP INVOICE DISTRIBUTIONS ALL"."AMOUNT"«0 AND NVL("AP INVOICE DISTRIBUT 
IONS ALL"."REVERSAL FLAG",'N')«»'Y' 
AND "AP INVOICE DISTRIBUTIONS ALL"."LINE TYPE LOOKUP CODE"-'PREPAY' AND 
NVL("AP INVOICE DISTRIBUTIONS ALL"."ORG ID",NVL(TO NUMBER (DECODE (SUBSTR 
Bi:Bi,1,1),! 
' , NULL, SUBSTRB (:B2,1,10))), (-99)) ) -NVL(TO NUMBER (DECODE (SUBSTRB(:B3,1,1 
),' ',NULL,SUBSTRB(:B4,1,10))), (-99))) 
19 - filter("AP INVOICE DISTRIBUTIONS ALL"."PREPAY DISTRIBUTION ID" IS NOT NULL) 
20 - filter (NVL("AP ' TAX CODES ALL"."ORG ID" (+) , NVL (TO NUMBER (DECODE (SUBSTRB(:B1,1,1), ' 
,NULL,SUBSTRB(:B2,1,10))), (-99))) -NVL(TO NUMBER (DECODE (SUBSTRB (:B3,1,1 
у, ey МОЕТ, SUBSTRB(: B4,1,10))), (-99))) 
21 - access ("АР INVOICE DISTRIBUTIONS ALL". "TAX CODE ID"-"AP TAX CODES ALL"."TAX ID 
Ы), 
22 - filter (МУ ("РО DISTRIBUTIONS ALL"."ORG Ір" (+), МУГ (ТО NUMBER (DECODE (SUBSTRB (: B1 
;1,1)," 
', NULL, SUBSTRB (:В2,1,10))), (-99))) -NVL(TO NUMBER (DECODE (SUBSTRB (:B3,1,1 
),' ',NULL,SUBSTRB(:B4,1,10))), (-99))) 
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23 - access ("AP INVOICE DISTRIBUTIONS ALL"."PO DISTRIBUTION ID"="PO DISTRIBUTIONS A 
LL"."PO DISTRIBUTION ID" 
(+)) 
24 - filter(NVL("PO HEADERS ALL"."ORG Ір" (+), ҮІ (ТО. NUMBER (DECODE (SUBSTRB (: Bi,1,1),' 
' , NULL, SUBSTRE (:B2, 1, 10) ) ) , (-99)) ) -NVL(TO NUMBER (DECODE (SUBSTRB (:В3,1,1 
),' ', NULL, SUBSTRB(:B4,1,10))), (-99))) 
25 - access ("РО DISTRIBUTIONS ALL"."PO HEADER ID"-"PO HEADERS ALL"."PO HEADER ID" (+)) 
26 - filter(NVL("PO LINE LOCATIONS ALL"."ORG ID"(+),NVL (TO NUMBER (DECODE (SUBSTRB (:B 
Y, h, My kt 
' NULL, SUBSTRB (:В2,1,10))), (-99)) ) -NVL (TO NUMBER (DECODE (SUBSTRB (:В3,1,1 
),' ',NULL,SUBSTRB (:B4, 1,10))) , (-99))) 
27 - access("PO DISTRIBUTIONS ALL"."LINE LOCATION ID"-"PO LINE LOCATIONS ALL"."LINE 
LOCATION ID" (+)) 
28 - filter(NVL("PO LINES ALL"."ORG ID"(*),NVL(TO NUMBER (DECODE (SUBSTRB (:B1, 1,1), ' 
', NULL,SUBSTRB(:B2,1,10))), (-99))) -NVL(TO NUMBER (DECODE (SUBSTRB (:B3,1,1 
),' ',NULL,SUBSTRB (:84,1,10))), (-99))) 
29 - access("PO LINE LOCATIONS ALL"."PO LINE ID"-"PO LINES ALL"."PO LINE ID"(*)) 
31 - access("AP INVOICE DISTRIBUTIONS ALL"."RCV TRANSACTION ID"-"RTXNS"."TRANSACTIO 
N ID"(4)) 
733 - access("RTXNS"."SHIPMENT LINE ID"-"RSL"."SHIPMENT LINE ID"(*)) 
34 - access("RSL"."SHIPMENT HEADER ID"-"RSH"."SHIPMENT HEADER ID" (+) ) 
35 - filter(NVL("AP INVOICE DISTRIBUTIONS ALL"."ORG ID",NVL(TO NUMBER (DECODE (SUBSTR 
B(:B1,1,1), ' 
' , NULL, SUBSTRB (:В2,1,10))), (-99)) ) -NVL(TO NUMBER (DECODE (SUBSTRB (:B3, 1, 1 
),' ',NULL,SUBSTRB (:B4, 1, 10))) , (-99))) 
36 - access("AP INVOICE DISTRIBUTIONS ALL"."PREPAY DISTRIBUTION ID"-"AP INVOICE DIS 
TRIBUTIONS ALL"."INVOICE 
DISTRIBUTION ID") 
37 - filter(NVL("AP INVOICES ALL"."ORG ID",NVL(TO NUMBER (DECODE (SUBSTRB (:B1, 1,1), ' 
' , NULL, SUBSTRB ( :B2, 1, 10) ) ) , (-99))) -NVL (TO NUMBER (DECODE (SUBSTRB (:B3,1,1 
),' ',NULL,SUBSTRB (:84,1,10))) , (-99))) 
38 - access("AP INVOICES ALL"."INVOICE ID"-"AP INVOICE DISTRIBUTIONS ALL"."INVOICE _ 
ID") 
39 - filter(NVL("PO VENDOR SITES ALL"."ORG ID",NVL(TO NUMBER (DECODE (SUBSTRB (:B1,1,1),' 


' , NULL, SUBSTRB (:B2,1, 10))), (-99)) ) -NVL (TO | NUMBER (DECODE (SUBSTRB (:B3,1,1 
);' ' , NULL, SUBSTRB (: B4,1,10))), (-99))) 


40 - access ("АР INVOICES ALL"."VENDOR SITE Ір"="РО VENDOR SITES ALL"."VENDOR SITE I 
р") 
41 - access ("АР INVOICES ALL"."VENDOR ID"="PV"."VENDOR ID") 


Note: cpu costing is off 


从 执行 计划 中 Id=5 看 到 ,该 SQL 发 生 了 连接 列 谓词 推 入 ,视图 AP UNAPPLY PREPAYS V 
被 当 作 了 抠 套 循环 的 被 驱动 表 。 原 始 SQL 中 ， 两 表 的 关联 条 件 如 下 。 


і WHERE A.INVOICE Ір = B.INVOICE ID(*) 


视图 中 B.INVOICE ID 来 自 于 АШІЛМУОІСЕ ID INVOICE ID， 因 此 ， 我 们 应 该 检查 执 
行 计划 中 AIDI.INVOICE ID INVOICE ID 是 否 走 了 索引 。 我 们 从 执行 计划 中 Id=18 发 现 如 下 。 
| 18 = filter("A"."INVOICE ID"-"AP INVOICE DISTRIBUTIONS ALL"."INVOICE ID" 

这 里 是 将 连接 列 谓词 推 入 到 执行 计划 中 14-18 进行 的 过 滤 操 作 , 并 不 是 将 连接 列 谓词 推 入 
视图 让 表 AP INVOICE DISTRIBUTIONS Ë INVOICE ID 的 索引 。 这 显然 大 错 特 错 了 。 

因为 发 生 了 谓词 推 入 , 视图 АР UNAPPLY PREPAYS V 作为 嵌 套 循环 被 驱动 表 会 被 多 次 
扫描 。 这 里 的 谓词 推 入 的 时 候 只 是 起 的 过 滤 作 用 ， 并 没有 走 谓词 连接 列 索引 。 因 此 ， 我 们 使 用 
HINT: USE HASH(A,B)， 让 两 表 走 HASH 连接 ， 从 而 避免 视图 被 多 次 反复 扫描 。 添 加 HINT 
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жож зем — — 
之 后 ，SQL 能 在 1 秒 返 回 结果 。 
我 们 也 可 以 调整 隐 含 参数 ， 关 闭 连接 列 谓词 推 入 。 


| ALTER SESSION SET " push join predicate" = FALSE; 


禁止 连接 列 谓词 推 入 ， 也 能 达到 效果 。 

我 们 还 可 以 检查 表 АР INVOICE DISTRIBUTIONS 表 的 INVOICE ID 列 是 否 存 在 索引 ， 
如 果 没 有 索引 ， 可 以 建立 一 个 索引 ， 从 而 实现 真正 的 连接 列 谓词 推 入 。 但 是 因为 当时 使 用 
USE HASH 已 经 优化 了 SQL， 所 以 没有 继续 检查 。 

最 终 的 SQL 如 下 。 


SELECT * 
FROM (SELECT Ў*#Жйзе НавҺһ(а/Б) %7 A.INVOICE ID, 
A.VENDOR ID, 
A.INVOICE NUM, 
A.INVOICE AMOUNT, 
A.GL DATE, 
A.INVOICE CURRENCY CODE, 
SUM(NVL(B.PREPAY AMOUNT APPLIED, 0)) PAID AMOUNT, 
A.INVOICE AMOUNT - SUM(NVL(B.PREPAY AMOUNT APPLIED, 0)) REMAIN 
FROM ap.AP INVOICES ALL A, APPS.AP UNAPPLY PREPAYS V B 
WHERE A.INVOICE ID - B.INVOICE ID(*) 
AND A.ORG ID - 126 /*:B4*/ 
AND A.SOURCE = 'OSM IMPORTED' /*:B3*/ 
AND A.INVOICE NUM BETWEEN NVL( /*:B2*/ null, A.INVOICE NUM) AND 
NVL( /*:B1*/ null, A.INVOICE NUM) 
GROUP BY A.INVOICE ID, 
A.INVOICE NUM, 
A.INVOICE AMOUNT, 
A.VENDOR ID, 
A.GL DATE, : 
A.INVOICE CURRENCY CODE) 
WHERE REMAIN > 0 ; 


添加 HINT 后 的 执行 计划 如 下 。 


| Id [Operation | Name IRows|Bytes |Cost| 
| 0 ISELECT STATEMENT | k. uH. 69) 7231 
|* 1 | FILTER | | | | | 
| 2 | SORT GROUP BY | | 1| 69| 723| 
[*^ 3*1 HASH JOIN OUTER | | 3| 207| 698| 
]*.4 | TABLE ACCESS FULL |AP INVOICES ALL | 3| 153| 694| 
р 59] VIEW |AP UNAPPLY PREPAYS V | 1| 18| 3| 
| 16; 1 NESTED LOOPS | | th 3142] 3| 
ЕУ NESTED LOOPS | | 1| 368| 3] 
| 8 | NESTED LOOPS | | 11 361) 21 
| $91 NESTED LOOPS | | 1| 347| 11 
|191 МЕ5ТЕр ІООР5 OUTER | | 1| 334| 1| 
ps NESTED LOOPS OUTER | | i| 321) 1| 
| 32:1 NESTED LOOPS OUTER | | i| 295] 11 
(23 | NESTED LOOPS OUTER | | 1| 269| 1| 
| 14 | NESTED LOOPS OUTER | | 1| 245] 1 
| 29) | NESTED LOOPS OUTER | | 11 187) 11 
| -E67 NESTED LOOPS OUTER | | 21” 2871 1| 
|, 27-2) NESTED LOOPS OUTER | | 1| 98| 1| 
P5438 | TABLE ACCESS BY INDEX ROWID|AP INVOICE DISTRIBUTIONS ALL| 1| 721 11 
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9.26 ”谓词 推 入 优化 案例 




















|%19 INDEX FULL SCAN |AP INVOICE DISTRIBUTIONS N20| 1 
|*20 TABLE ACCESS BY INDEX ROWID|AP TAX CODES ALL 1| 26 
|*21 INDEX UNIQUE SCAN AP TAX CODES Ul .. 1 
|%22 TABLE ACCESS BY INDEX ROWID|PO DISTRIBUTIONS ALL 1| 59 
|*23 INDEX UNIQUE SCAN PO DISTRIBUTIONS Ul 1 
*24 | TABLE ACCESS BY INDEX ROWID |PO HEADERS ALL ПТ” 
*25 | INDEX UNIQUE 5САМ PO HEADERS Ul 
*26 TABLE ACCESS BY INDEX ROWID |PO LINE LOCATIONS ALL 46 
*27 INDEX UNIQUE SCAN PO LINE LOCATIONS 01 1 
*28 TABLE ACCESS BY INDEX ROWID |РО LINES ALL »| 96 
*29 INDEX UNIQUE SCAN PO LINES Ul L 
30 TABLE ACCESS BY INDEX ROWID RCV TRANSACTIONS 1| 26 
*31 INDEX UNIQUE SCAN RCV TRANSACTIONS Ul 1 
32 TABLE ACCESS BY INDEX ROWID RCV SHIPMENT LINES 1| 26 
*33 | INDEX UNIQUE SCAN |RCV SHIPMENT LINES Ul ü 
*34 | INDEX UNIQUE SCAN RCV SHIPMENT HEADERS Ul T) cedes 
*35 TABLE ACCESS BY INDEX ROWID AP INVOICE DISTRIBUTIONS ALL| 1| 131 
|%36 INDEX UNIQUE 5САМ AP INVOICE DISTRIBUTIONS U2 | 1 
*37 TABLE ACCESS BY INDEX ROWID AP INVOICES ALL 3p "ауен 
|*38 INDEX UNIQUE SCAN AP INVOICES Ul 1 | 
*39 TABLE ACCESS BY INDEX ROWID PO VENDOR SITES ALL 1 Ri] pt 
*40 INDEX UNIQUE SCAN PO VENDOR SITES Ul 1 
*41 INDEX UNIQUE SCAN PO VENDORS Ul 1 4 











Predicate Information (identified by operation id): 


1 = filter("A". "INVOICE AMOUNT"-SUM (NVL("B"." PREPAY AMOUNT APPLIED" ,0))>0) 
3 - access("A"."INVOICE ID"-"B"."INVOICE ID" (+)) 
4 = filter("A"."ORG ID"-126 AND "A"."SOURCE"-'OSM IMPORTED' AND 
"A"."INVOICE NUM"»-NVL (NULL, "А". "ІМҮОІСЕ NUM") AND "A"."INVOICE NUM"«-N 
VL(NULL,"A"."INVOICE NUM")) 
18 - filter("AP INVOICE DISTRIBUTIONS ALL"."AMOUNT"«0 AND 
NVL ("AP INVOICE DISTRIBUTIONS ALL" 4 "REVERSAL FLAG" М) GS t. AND 
"AP INVOICE DISTRIBUTIONS ALL"."LINE TYPE LOOKUP CODE"-'PREPAY' AND 
NVL("AP INVOICE DISTRIBUTIONS ALL"."ORG ID",NVL(TO NUMBER (DECODE (SUBSTR 
BirBi i, 1)," 
',NULL,SUBSTRB(:B2,1,10))), (-99) ) ) ENVL (TO NUMBER (DECODE (SUBSTRB (:B3,1,1 
),' ',NULL,SUBSTRB(:B4,1,10))), (-99))) 
19 - filter("AP INVOICE DISTRIBUTIONS ALL"."PREPAY DISTRIBUTION ID" IS NOT NULL) 
20 - filter (NVL ("AP_ TAX CODES ALL"."ORG Ір" (+), NVL (TO NUMBER (DECODE (SUBSTRB (:B1, 1,1), ' 
' NULL, SUBSTRB (:B2,1,10))), (-99))) -NVL(TO NUMBER (DECODE (SUBSTRB (:B3,1,1 
),' ',NULL,SUBSTRB(:B4,1,10))), (-99))) 
21 - access("AP INVOICE DISTRIBUTIONS ALL"."TAX CODE ID"-"AP TAX CODES ALL"."TAX ID 
"UG 
22 - filter(NVL("PO DISTRIBUTIONS ALL"."ORG ID"(4),NVL(TO NUMBER (DECODE (SUBSTRB (:B1 
ГА iy T) , Т 
', NULL, SUBSTRB (:В2,1,10))), (-99)))-NVL(TO NUMBER (DECODE (SUBSTRB (:B3,1,1 
),' ',NULL,SUBSTRB(:B4,1,10))), (-99))) 
23 - access("AP INVOICE DISTRIBUTIONS ALL"."PO DISTRIBUTION ID"-"PO DISTRIBUTIONS A 
LL"."PO DISTRIBUTION ID" I f š 
(+)) 
24 - filter(NVL("PO HEADERS ALL"."ORG Ір" (+), NVL (TO_NUMBER (DECODE (SUBSTRB (:B1, 1, 1), ' 
,NULL,SUBSTRB(:B2,1,10))), (-99)))=NVL(TO NUMBER (DECODE (SUBSTRB (:B3, 1,1 
),' ',NULL,SUBSTRB(:B4,1,10))), (-99))) Ж 
25 - access("PO DISTRIBUTIONS ALL"."PO HEADER ID"-"PO HEADERS ALL"."PO HEADER ID" (+)) 
26 - filter(NVL("PO LINE LOCATIONS ALL"."ORG ID"(*),NVL(TO NUMBER (DECODE (SUBSTRB (: B 
V; doy; 


; NULL, SUBSTRB(:B2,1,10))), (-99)) ) -NVL(TO NUMBER (DECODE (SUBSTRB (:B3,1,1 
),' ',NULL,SUBSTRB (:B4,1,10))) , (-99) )) 
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27 - access("PO DISTRIBUTIONS ALL"."LINE LOCATION ID"-"PO LINE LOCATIONS ALL"."LINE 
LOCATION ID" (+) ) 

28 - filter(NVL("PO LINES ALL"."ORG Ір" (+), МУГ (ТО NUMBER (DECODE (SUBSTRB (:B1,1,1), ' 

', NULL,SUBSTRB(:B2,1,10))), (-99)) ) ENVL(TO NUMBER (DECODE (SUBSTRB (:В3,1,1 

);' ',NULL,SUBSTRB(:B4,1,10))), (-99))) 

29 - access("PO LINE LOCATIONS ALL"."PO LINE ID"-"PO LINES ALL"."PO LINE Ір" (+)) 

31 - access("AP INVOICE DISTRIBUTIONS ALL"."RCV TRANSACTION ID"-"RTXNS"."TRANSACTIO 
N Ір" (+)) 

33 - access ("КТХМЅ". "ЗНІРМЕМТ LINE ID"-"RSL"."SHIPMENT LINE Ір" (+)) 

34 - access("RSL"."SHIPMENT HEADER ID"-"RSH"."SHIPMENT HEADER Ір" (+)) 

35 - filter(NVL("AP INVOICE DISTRIBUTIONS ALL"."ORG ID",NVL(TO NUMBER (DECODE (SUBSTR 
B(:B1,1,1),' 





' NULL, SUBSTRB (:B2,1,10))), (-99)) ) -RVL(TO NUMBER (DECODE (SUBSTRB (:B3,1,1 
),' ', NULL, SUBSTRB(:B4,1,10))), (-99))) 
36 - access("AP INVOICE DISTRIBUTIONS ALL"."PREPAY DISTRIBUTION ID"-"AP INVOICE DIS 
TRIBUTIONS ALL"."INVOICE 
DISTRIBUTION ID") 
37 - filter(NVL("AP INVOICES ALL"."ORG Ір", МҮ (ТО NUMBER (DECODE (SUBSTRB(:B1,1,1),' 


', NULL, SUBSTRB (:В2,1,10))), (-99) ) ) -NVL(TO NUMBER (DECODE (SUBSTRB (:B3,1,1 
),' ',NULL,SUBSTRB(:B4,1,10))), (-99))) 
38 - access("AP INVOICES ALL"."INVOICE ID"-"AP INVOICE DISTRIBUTIONS ALL"."INVOICE 





ID" 
39 - filter (МУГ ("РО VENDOR SITES ALL"."ORG ID",NVL(TO NUMBER (DECODE (SUBSTRB(:B1,1,1),"' 
T NULL, SUBSTRB (:82,1,10))), (7-99) )) -NVL (TO NUMBER (DECODE (SUBSTRB(:B3,1,1 
),' ',NULL,SUBSTRB(:B4,1,10))), (-99))) 
40 - access ("AP INVOICES ALL" k "VENDOR_SITE_ID"=" PO VENDOR SITES ALL" Š "VENDOR SITE I 
р") 
41 - access ("АР INVOICES ALL"."VENDOR ID"-"PV"."VENDOR ID") 

水 平 高 的 读者 或 许 有 疑问 , 执行 计划 Id=19 是 INDEX FULL SCAN， 然 后 再 回 表 过 滤 ， 这 
里 也 有 性 能 问题 ， 全 表 扫 描 效 率 应 该 也 比 INDEX FULL SCAN 再 回 表 效 率 高 ! 是 的 ， 我 们 也 
发 现 了 这 个 地 方 有 性 能 问题 ， 但 是 既然 SQL 都 执行 到 1 秒 了 ， 也 就 没 继 续 优 化 了 ， 干 万 别 得 
了 优化 强迫 症 。 

最 后 ， 我 们 再 次 强调 ， 如 果 发 生 了 连接 列 谓词 推 入 ,一 定 要 检查 执行 计划 中 是 否 走 了 谓词 


被 推 入 的 表 的 连接 列 索引 。 






2011 年 ， 一 位 ITPUB 的 网 友 请 求 优化 如 下 SQL, iX SQL 执行 不 出 结果 。 


SQL> explain plan for select ((v.yvalue * 300) / (u.xvalue * 50)), u.xtime 


2 from (select х.іпдех value xvalue, substr(x.update time, 1, 14) xtime 
3 from tb indexs x 

4 where x.id in (select min(a.id) 

5 from tb indexs a 

6 where a.code - 'HSI' 

б апа a.update time > 20110701000000 

8 and a.update time < 20110722000000 

9 group by a.update time)) u, 

10 (select у.іпдех value yvalue, substr(y.update time, 1, 14) ytime 
11 from tb indexs y 
12 where y.id in (select min(b.id) 

13 from tb indexs b 

14 where b.code = "000300" 

15 and b.update time » 20110701000000 

16 and b.update time « 20110722000000 


9.27 使 用 CARDINALITY 优化 SQL 


17 group by b.update time)) v 
18 where u.xtime = v.ytime 
19 order by u.xtime; 

Explained. 

SQL» select * from table(dbms xplan.display); 


PLAN TABLE OUTPUT 


Plan hash value: 573554298 











| Id | Operation | Name Rows | Bytes | Cost (SCPU) | 
| 0 | SELECT STATEMENT | Au 54 | 43 (8) 
| 11 SORT ORDER BY | | 47) 54 144 X8] 
Еу! NESTED LOOPS | | 17) 54 127 X01 
| 3 1 MERGE JOIN CARTESIAN | 1-1 33 | 10 (0)| 
| 4il NESTED LOOPS | | q^ 21 6 (0)! 
[- 8 | VIEW | VW_NSO_2 | їй 6 4 (б) 
| | HASH GROUP BY | | 1 | 41 4 (0) 
a «т TABLE ACCESS BY INDEX ROWID| TB INDEXS y 3 41 4 (0) 
[285.11 INDEX RANGE SCAN | IDX UPDATE TIME Tl | з (0) 
I9 TABLE ACCESS BY INDEX ROWID | TB INDEXS d. M Zu | 2 (0) 
[10 | INDEX UNIQUE SCAN | PK INDEXS LJ 1. (0) 
| 2171 BUFFER SORT | 1 1 6 | 8 (0) 
|12 | VIEW | VW_NSO_1 ? 4 6 4 (0)| 
| 33 HASH GROUP BY | | 1 | 41 | 4 (0) 
| 14 | TABLE ACCESS BY INDEX ROWID| TB INDEXS | 2171 41 | 4 (0)! 
|*15 | INDEX RANGE SCAN | IDX UPDATE TIME | 1) 325 709)1 
|%16 | TABLE ACCESS BY INDEX ROWID | TB INDEXS | geri 21 2 300) 
1*17 | INDEX UNIQUE SCAN | PK INDEXS | às] 1 (0) 


Predicate Information (identified by operation id): 


8 - access("A"."UPDATE ТІМЕ">20110701000000 AND "A"."CODE"-'HSI' AND 
"A"."UPDATE TIME"«20110722000000) 
filter("A"."CODE"-'HSI!) 
10 ~ access("X"."ID"-"$nso col 1") 
15 - access("B"."UPDATE ТІМЕ">20110701000000 AND "B"."CODE"-'000300' AND 
"B"."UPDATE TIME"«20110722000000) 
filter ("B"."CODE"-'000300') 
16 - filter(SUBSTR(TO CHAR("X"."UPDATE TIME"),1,14)-SUBSTR(TO CHAR("Y"."UPDATE TIME 
"),1,14) 
) 


17 = access("Y"."ID"2s"$nso col 1") 


38 rows selected. 


大 家 请 仔细 观察 SQL 语句 ， 该 SQL 访问 的 都 是 同一 个 表 TB INDEXS, KE SQL 语句 中 
被 访问 了 4 次, 我 们 可 以 对 SQL 进行 等 价 改写 , 让 SQL 只 访问 一 次 , 从 而 就 达到 了 优化 目的 。 
但 是 ， 网 友 希 望 在 不 改写 SQL 的 前 提 下 优化 该 SQL 语句 ， 因 此 只 能 从 执行 计划 入 手 优化 
SQL。 执 行 计 划 中 ，Id=3 是 笛 卡 儿 积 ， 这 就 是 为 什么 该 SQL 执行 不 出 结果 。 为 什么 会 产生 笛 
卡 儿 积 呢 ? 因为 执行 计划 中 所 有 的 步骤 Rows 都 估算 返回 为 1 行 数据 ,所 以 优化 器 选择 了 笛 卡 
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儿 积 连接 (在 5.4 节 中 我 们 讲 过 ， 离 笛 卡 儿 积 关键 字 最 近 的 “ 表 ” 被 错误 地 估算 为 1 行 的 时 候 ， 
优化 器 很 容易 选择 走 笛 卡 儿 积 连 接 )。 

执行 计划 的 入 口 是 Id=8， 也 就 是 SQL 语句 中 的 in 子 查询 ， 优 化 器 评估 Id=8 返回 1 行 数 
Hi, 但 是 实际 上 Id=8 要 返回 2 万 行 数据 。 笔 者 曾经 尝试 对 表 TB. INDEXS 重新 收集 统计 信息 ， 
但 是 收集 完 统计 信息 之 后 ， 优 化 器 还 是 评估 Id=8 返回 1 行 数 据 。 

为 什么 优化 器 会 评估 Id=8 返回 1 行 数据 呢 ? 这 是 因为 字段 UPDATE TIME 被 设计 为 了 
NUMBER 类 型 ， 而 实际 上 UPDATE TIME 应 该 是 DATE 类 型 ,同时 where 条 件 中 还 有 一 个 选 
择 性 较 低 的 过 滤 条 件 ， 优 化 器 估算 返回 的 行 数 等 于 表 的 总 行 数 与 UPDATE TIME 的 选择 性 、 
CODE 的 选择 性 的 乘积 。UPDATE TIME 因为 字段 类 型 设计 错误 ， 本 来 应 该 估算 返回 21 天 的 
数据 , 但 是 因为 UPDATE TIME 设计 为 了 NUMBER 类 型 ， 导 致 优化 器 在 估算 返回 行 数 的 时 候 
不 是 利用 DATE 类 型 估算 返回 行 数 ， 而 是 利用 NUMBER 类 型 估算 返回 行 数 。 大 家 请 注意 观察 
UPDATE TIME 的 过 滤 条 件 ， 将 年 月 日 存储 为 NUMBER 类 型 是 一 个 天 文 数 字 ， 然 后 where 条 
件 只 是 取出 一 个 天 文 数字 中 极 小 一 部 分 数据 ， 因 此 估算 返回 的 行 数 始终 会 被 估算 为 1 行 ， 

因为 执行 计划 入 口 的 Rows 估算 错误 ， 所 以 后 面 的 执行 计划 不 用 看 ， 全 是 错误 的 。 因 为 
UPDATE TIME 已 经 被 设计 为 NUMBER 类 型 了 ， 想 要 通过 修改 UPDATE TIME 为 DATE 类 
型 来 纠正 优化 器 估算 返回 的 Rows 是 不 可 行 的 ， 因 为 需要 申请 停机 时 间 。 

怎么 才 可 以 让 优化 器 知道 真实 Rows 呢 ? 我 们 可 以 使 用 HINT: CARDINALITY。 

/*+ cardinality(a 10000) */ 表 示 指 定 a 表 有 1 万 行 数据 。 

/*-- cardinality(@a 10000) */ 表 示 指 定 query block a 有 1 万 行 数据 。 

添加 完 HINT 后 的 执行 计划 如 下 。 


SOL» set autot trace 


SOL» select /x+ cardinality(Ga 20000) cardinality(8b 20000) */((v.yvalue * 300)/(u.xv 
alue * 50)), u.xtime 


2 from (select x.index value xvalue, substr(x.update time, 1, 14) xtime 
3 from tb indexs x 
4 where x.id in (select /*+ QB NAME(a) */ min(a.id) 
5 from tb indexs a 
6 where a.code - 'HSI' 
7 and a.update time » 20110701000000 
8 and a.update time « 20110722000000 
9 group by a.update time)) u, 
10 (select у.іпдех value yvalue, substr(y.update time, 1, 14) ytime 
11 from tb indexs y 
12 where y.id in (select /*+ ОВ NAME(b) */ min (b.id) 
13 from tb indexs b 
14 where b.code = '000300' 
15 and b.update time » 20110701000000 
16 and b.update time « 20110722000000 
17 group by b.update time)) v 
18 where u.xtime = v.ytime 
19 order by u.xtime; 





3032 rows selected. 
Elapsed: 00:00:15.07 


Execution Plan 


9.27 使 用 CARDINALITY 优化 SQL 


Plan hash value: 2679503093 


| Id | Operation | Name | Rows| Bytes |Cost($CPU) | 
| 0 | SELECT STATEMENT І | 935| 50490 | 1393 (7)| 
| 1 | SORT ORDER BY | |. 935| 30490: 4,1393. (7) | 
ж 2 HASH JOIN | |>v'939:|” 50450' T 1392 (71 
=з | VIEW | VW_NSO_1 |20000| 117К| 4 (0)| 
| 414 НА5Н GROUP ВУ | 120000| 800K| 4 (0)| 
5. | TABLE ACCESS BY INDEX ROWID | TB INDEXS | 1T 41 | 4 (0)| 
|*= 1 INDEX RANGE SCAN | IDX UPDATE TIME | 1| | 35. (09521 
pe] HASH JOIN | 131729| 1487К| 1386 (7)| 
194821 HASH JOIN | 120000] 527K| “695 . (7) 
[5791 VIEW | VW_NSO_2 120000| 117K| 4 (0)| 
121979] НАЅН GROUP BY | |20000| 800K| 4 (ОҒ) 
| 32 | TABLE ACCESS BY INDEX ROWID| TB INDEXS | 1] 41 | 4 (0)| 
2227 | INDEX RANGE SCAN | IDX UPDATE TIME | 1| | а t9 
1 3361 TABLE ACCESS FULL | TB INDEXS | 678K| 13M| 678 (5)| 
| 14 | TABLE ACCESS FULL | TB INDEXS | 678K| 13M| 678. (5) 


2 - aeccess("Y","ID"s"$nso col 1") 
6 - access("B"."UPDATE ТІМЕ">20110701000000 AND "B"."CODE"-'000300' AND 
"B"."UPDATE TIME"«20110722000000) 
filter("B"."CODE"-'000300') 
7 - access (SUBSTR (TO CHAR("X"."UPDATE TIME"),1,14)-SUBSTR(TO CHAR("Y"."UPDATE TIME 
"),1,14) 
) 
8 = access("X"."ID"s"$nso col 1") 
12 - access("A"."UPDATE ТІМЕ">20110701000000 AND "A"."CODE"-'HSI' AND 
"A"."UPDATE TIME"«20110722000000) 
filter("A"."CODE"-'HSI') 


Statistics 


recursive calls 
db block gets 
consistent gets 
physical reads 
redo size 


bytes sent via SQL*Net to client 
bytes received via SQL*Net from client 
204 SQL*Net roundtrips to/from client 
1 sorts (memory) 
0 sorts (disk) 
rows processed 


通过 指定 执行 计划 入 口 〈 子 查询 ) 返回 2 万 行 数据 ， 纠 正 了 之 前 错误 的 执行 计划 ，SQL 
最 终 执 行 了 15 秒 就 返回 了 所 有 的 结果 。 

如 果 不 知道 有 CARDINALITY 这 个 HINT， 怎 么 优化 SQL We? 我们 可 以 启用 动态 采样 
Level 4 及 以 上 (最 好 别 超过 6)， 让 优化 器 能 较为 准确 地 评估 出 子 查询 返回 的 Rows， 这样 也 能 
达到 优化 目的 。 如 果 不 知道 动态 采样 怎么 优化 SQL 呢 ? 我 们 可 以 直接 使 用 HINT， 比 如 
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жож зажив a ss s 
USE HASH ^£, iË SQL 走 我 们 认为 正确 的 执行 计划 也 能 达到 优化 目的 。 当 然 了 ， 最 佳 的 优化 
方法 应 该 是 直接 从 业务 上 入 手 ， 从 表 设 计 上 入 手 ， 从 SQL 写法 上 入 手 ， 而 不 是 退 而 求 其 次 从 
执行 计划 入 手 ， 但 是 很 多 时 候 我 们 往往 只 能 从 执行 计划 上 入 手 优化 SQL， 这 或 许 是 绝 大 多 数 


DBA 的 无 奈 。 
本 案例 博客 地 址 :http://blog.csdn.net/robinson1988/article/details/6626384。 


四 


本 案例 发 生 在 2010 年 ， 当 时 作者 罗 老 师 在 惠普 担任 开发 DBA， 支 撑 宝 洁 公司 的 数据 仓库 
项 目 。ETL 开发 人 员 需 要 帮助 调查 一 个 long running 的 JOB, iZ JOB 执行 了 7 个 小 时 还 没 执行 
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数据 库 环境 为 11.1.0.7 (ВАС, 4314). 


SQL» select * from v$version; 


Oracle Database 11g Enterprise Edition Release 11.1.0.7.0 - 64bit Production 


数据 块 大 小 为 16k。 


SQL> show parameter db block size 


db block size integer 16384 


执行 得 慢 的 JOB 是 一 个 insert into ...select 语句。 一 般 情 况 下 ， 如 果 select 语句 跑 得 快 ， 
那么 整个 JOB 也 就 跑 得 快 ， 因 此 我 们 应 该 把 主要 精力 放 在 select 语句 上 面 。select 部 分 的 SQL 
语句 如 下 ， 这 是 一 个 接近 400 行 的 SQL (因为 SQL 实在 太 长 ， 所 以 没有 对 SQL 格式 化 )。 


SELECT АСТУҮ SKID, FUND_SKID, PRMTN_SKID, PROD SKID,DATE SKID; 

ACCT SKID,BUS UNIT SKID, FY DATE SKID,ESTMT VAR | COST AMT,ESTMT FIXED COST AMT, 
REVSD | ESTMT VAR | COST | AMT, АСТЫ. VAR | COST AMT, АСТЫ. FIXED | COST. ; AMT, COST PLAN AMT, 
COST. | CMMT AMT, COST | BOOK _ AMT, ESTMT | COST OVRRD AMT,LA TOT BOOK AMT, 

MANUL | COST | OVRRD . AMT, ACTL 26087.” АМТ 

FROM (SELECT ACTVY . SKID, FUND | SKID, PROD SKID,PRMTN SKID,DATE SKID,ACCT SKID, 
BUS UNIT SKID,FY . DATE | SKID,ESTMT | VAR . COST AMT, ESTMT - FIXED COST | AMT, 

REVSD _ ESTMT VAR | COST AMT, 0 as ACTL £057 AMT, ACTL VAR COST AMT, ACTE ` FIXED COST AMT, 
MANUL | | COST | OVRRD ， AMT,ESTMT COST | OVRRD AMT, COST . BOOK | AMT, 

== Updated | by Luke for QC3369 

-- If the committed amount on Activity level «0 then return 0 

(CASE WHEN SUM(ESTMT COST OVRRD AMT - ACTL VAR COST AMT - 

ACTL FIXED COST AMT) OVER (PARTITION BY ACTVY  SKID) < 0 THEN 0 

ELSE COST | CMMT ' AMT END) AS COST CMMT AMT, 

z2 Updated by Luke for QC3369 

(CASE WHEN SUM(ESTMT COST OVRRD AMT - ACTL VAR COST AMT - 

ACTL FIXED COST AMT) OVER(PARTITION BY ACTVY SKID) < 0 THEN 0 

ELSE COST PLAN AMT END) AS COST PLAN AMT,LA TOT BOOK AMT 

FROM (SELECT ACTVY SKID,FUND SKID,PROD SKID,PRMTN SKID, 

DATE SKID,ACCT SKID,BUS UNIT SKID,FY DATE SKID,ESTMT VAR COST AMT, 











9.28 利用 等 待 事件 优化 SQL 


ESTMT FIXED COST AMT,REVSD ESTMT VAR COST | AMT, ACTL VAR COST AMT, 

АСТ. FIXED | COST AMT, MANUL | COST | OVRRD AMT, 

(CASE WHEN SUBSTR(ESTMT ， COST IND, 1, 1) 9 'E' THEN 

ESTMT FIXED COST AMT + ESTMT "VAR _ COST AMT WHEN SUBSTR(ESTMT | COST CIND; ly 1) = "ЫТЫЫ 

N ESTMT FIXED | COST | AMT + DECODE (REVSD | ВРТ COST AMT,O0,REVSD | ESTMT МАК COST AMT, 

--Ax Revised Estimated Variable Cost REVSD | BPT COST AMT) --BPT Revised Cost 

WHEN SUBSTR(ESTMT COST IND, 1, 1) = "М! THEN MANUL | COST OVRRD AMT 

WHEN ESTMT COST IND IS NULL THEN DECODE (CORP. PRMTN | TYPE CODE, 

'Annual Agreement', ESTMT FIXED COST AMT + DECODE(REVSD BPT COST АМТ,0, 

REVSD ESTMT VAR COST AMT, --Ax Revised Estimated Variable Cost 

REVSD BPT COST AMT), --BPT Revised Cost 

ESTMT FIXED COST AMT + ESTMT VAR COST AMT) END) AS ESTMT COST OVRRD AMT, 

(ACTL ' VAR | COST ^ AMT + ACTL ` FIXED | COST AMT) AS COST BOOK AMT, 

DECODE (PRMTN _ STTUS ‚ CODE, 'Confirmed', 

--Estimate Total Cost - Actual Cost 

--Add the logic of Activity Stop date and Pyment allow IND 

--For Defect 2913 Luke 2010-5-5 

(CASE WHEN (ACTVY STOP DATE IS NULL OR ACTVY STOP DATE » SYSDATE OR 

NVL(PYMT ALLWD . STOP ' IND, FN = Ny THEN (CASE WHEN SUBSTR(ESTMT COST IND, 1, 1) = ' 

E' THEN ESTMT_ FIXED | COST AMT + ESTMT VAR COST AMT WHEN SUBSTR(ESTMT | COST KIND; L, 1) 
'R' THEN ESTMT - FIXED COST AMT ^ DECODE (REVSD | BPT COST AMT,O,REVSD ESTMT VAR COST AMT, 

--Ax Revised Estimated Variable Cost 

REVSD BPT COST AMT) --BPT Revised Cost 

WHEN SUBSTR(ESTMT ， COST IND, 1, 1) - 'M' THEN MANUL COST OVRRD AMT 

WHEN ESTMT COST IND IS NULL THEN DECODE(CORP PRMTN TYPE CODE,'Annual Agreement', 

ESTMT FIXED COST AMT + DECODE(REVSD ВРТ COST AMT,O0,REVSD ESTMT VAR COST AMT, 

--Ax Revised Estimated Variable Cost 


lI 


REVSD BPT COST AMT), --BPT Revised Cost 
ESTMT FIXED COST AMT + ESTMT VAR COST AMT) END) - (ACTL VAR COST AMT + ACTL FIXED COS 
T AMT) 


ELSE 0 END), 0) AS COST CMMT AMT, (CASE WHEN (PRMTN STTUS CODE IN ('Planned', 'Revised 
') AND NVL(APPRV STTUS CODE, 'Nothing') <> 'Rejected' AND 

--Add the logic of Activity Stop date and Pyment allow IND 

--For Defect 2913 Luke 2010-5-5 

(ACTVY STOP DATE IS NULL OR ACTVY STOP DATE » SYSDATE OR NVL(PYMT ALLWD STOP IND, 'N' 


fus DENM 

THEN (CASE WHEN SUBSTR(ESTMT COST IND, 1, 1) = 'E' THEN ESTMT FIXED COST AMT + ESTMT 
VAR COST AMT 

WHEN SUBSTR(ESTMT COST IND, 1, 1) = 'R' THEN ESTMT FIXED COST АМТ + DECODE(REVSD BPT 


COST АМТ,0, REVSD ESTMT VAR COST AMT, --Ax Revised Estimated Variable Cost REVSD ВРТ. 
COST AMT) --BPT Revised Cost 

WHEN SUBSTR(ESTMT COST IND, 1, 1) - 'M' THEN MANUL COST  OVRRD AMT WHEN ESTMT COST IND 
IS NULL THEN DECODE (CORP _ PRMTN TYPE CODE, 'Annual Agreement', ESTMT | FIXED | COST AMT «DE 
CODE(REVSD BPT COST AMT, 0, 

REVSD ESTMT VAR COST . AMT, --Ax Revised Estimated Variable Cost 

REVSD | BPT COST AMT), --BPT Revised Cost 

ESTMT FIXED | COST AMT + ESTMT VAR COST AMT) END) - (ACTL VAR COST AMT + ACTL FIXED COS 
T AMT) ELSE 0 END) AS COST PLAN AMT, (CASE WHEN MTH START DATE » TRUNC (SYSDATE, "Мм"! ) 
AND PRMTN STTUS CODE IN (" Planned', 'Confirmed', 'Revised') THEN (CASE WHEN SUBSTR(E 
STMT COST IND, 1, 1)- 'E' THEN ESTMT FIXED |" COST AMT + ESTMT VAR COST AMT WHEN SUBSTR( 
ESTMT COST IND, 1, 1) = 'R' THEN ESTMT ， FIXED | COST | AMT + DECODE (REVSD _ ВРТ COST AMT,O,R 
EVSD ESTMT VAR COST AMT, 

--Ax Revised Estimated Variable Cost 

REVSD BPT COST AMT) --BPT Revised Cost 

WHEN SUBSTR(ESTMT COST IND, 1, 1) = 'M' THEN MANUL COST OVRRD AMT WHEN ESTMT COST IND 
IS NULL THEN DECODE(CORP PRMTN TYPE CODE,'Annual Agreement',ESTMT FIXED COST AMT *DE 

CODE(REVSD BPT COST АМТ,0, 

REVSD ESTMT VAR | COST AMT, --Ax Revised Estimated Variable Cost 

REVSD ` BP COST ' AMT), --BPT Revised Cost 

ESTMT FIXED COST AMT + ESTMT VAR COST AMT) END) 
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WHEN МТН START DATE <= TRUNC(SYSDATE, 'MM') THEN (ACTL VAR COST AMT + ACTL FIXED COST 
AMT) ELSE 0 END) AS LA TOT BOOK AMT FROM (SELECT ACTVY MTH GTIN.ACTVY SKID,ACTVY MT 
H GTIN.FUND SKID,ACTVY MTH GTIN.PROD SKID, 

ACTVY MTH GTIN.PRMTN SKID,ACTVY MTH GTIN.MTH SKID AS DATE SKID,ACTVY MTH GTIN.ACCT SK 
ID,ACTVY MTH GTIN.BUS UNIT SKID, 

ACTVY МТН GTIN.FY DATE SKID,PRMTN.PRMTN STTUS CODE, 


PRMTN. .APPRV | STTUS | CODE, ТАСТЎҮ. ESTMT COST _ IND, ACTVY. CORP PRMTN TYPE CODE,ACTVY.ACTVY ST 


OP DATE, 
ACTVY.PYMT ALLWD STOP IND,CAL. МІН. START DATE, ROUND(NVL(DECODE(ACTVY.COST TYPE CODE, '% 
Fund', (ACTVY | МТН | GTIN.ESTMT VAR | COST * -- added by Rita for defect 3105 in R10 


ACTVY MTH GTIN. ACTVY | GTIN ESTMT _WGHT " RATE), DECODE (ACTVY.CORP PRMTN TYPE CODE, 
'AnnualAgreement!', AA. .ESTMT VAR COST AMT, ESTMT VAR COST.ESTMT VAR COST AMT)),0),7) AS 
ESTMT VAR COST AMT, 

-- Modified by Simon For CR389 in R10 on 2010-3-18 
ROUND(NVL(DECODE(ACTVY.COST TYPE CODE, 

== Ж Fund 

'$ Fund',ACTVY МТН GTIN.ESTMT FIX COST % АСТУҮ МТН GTIN.ACTVY GTIN ESTMT WGHT RATE, 
-- Fixed 

'Fixed',ACTVY MTH GTIN.ESTMT FIX COST * ACTVY MTH GTIN.ACTVY GTIN ESTMT WGHT RATE, 
-- Not $ Fund or Fixed 

DECODE(DECODE(ACTVY.CORP PRMTN TYPE CODE,'Annual Agreement', 
SUM(NVL(AA.ESTMT VAR | COST AMT, 0))OVER(PARTITION BY ACTVY  MTH GTIN.ACTVY SKID), 

SUM (NVL (ESTMT ` VAR | COST.ESTMT ' VAR COST AMT, 0))OVER(PARTITION BY ACTVY MTH GTIN.ACTVY S 
KID)), 

0,АСТУҮ МТН GTIN.ESTMT FIX COST * BRAND МТН RATE,ACTVY МТН GTIN.ESTMT FIX COST * NVL( 
DECODE(ACTVY.CORP PRMTN TYPE CODE,'AnnualAgreement',AA.ESTMT VAR COST AMT,ESTMT VAR C 
OST.ESTMT VAR COST AMT),0) / DECODE(ACTVY.CORP PRMTN TYPE CODE,'Annual Agreement',SUM 
(NVL(AA.ESTMT VAR COST AMT,0)) 

OVER(PARTITION BY ACTVY MTH GTIN.ACTVY SKID),SUM(NVL(ESTMT VAR COST.ESTMT VAR COST AM 
"079 
OVER(PARTITION BY АСТУҮ МТН GTIN.ACTVY SKID)))),0),7) AS ESTMT FIXED COST AMT, 

-- Change in R10 for Revised Cost logic 
ROUND(NVL(DECODE(ACTVY.CORP PRMTN TYPE CODE,'Annual Agreement',AA.REVSD ESTMT VAR COS 
T AMT, 
REVSD VAR COST.REVSD ESTMT VAR COST AMT),0),7) AS REVSD ESTMT VAR COST AMT, 

ROUND (NVL (ESTMT - VAR | COST. REVSD | BPT COST AMT, 0), 7) AS REVSD | BPT COST ' AMT, 

ROUND (NVL ( (ACTVY | MTH | GTIN.ACTL ' УАВ. “COST * ACTVY  MTH GTIN. ACTVY GTIN AETLI WGHT RATE),0O 
Je Ti 

AS ACTL VAR COST AMT,ROUND(NVL((ACTVY MTH GTIN.ACTL FIX COST * ACTVY MTH GTIN.ACTVY G 
TIN ACTL МОНТ ВАТЕ),0 ),7) AS ACTL FIXED | COST | AMT, ROUND (NVL (DECODE (ACTVY . gost: TYPE | COD 
Ep's Pund", 

ACTVY MTH GTIN.MANUL COST OVRRD AMT * ACTVY MTH GTIN.ACTVY GTIN ESTMT WGHT RATE, 
'Fixed', ACTVY ‚ МҮН + GTIN.MANUL J COST | OVRRD AMT 7% ACTVY | MTH | GTIN. ACTVY | GTIN  ESTMT  WGHT RA 








ТЕ, 

DECODE(DECODE(ACTVY.CORP PRMTN TYPE CODE,'Annual Agreement',SUM(NVL(AA.ESTMT VAR COST 
AMT, 0)) 

OVER(PARTITION BY ACTVY MTH GTIN.ACTVY SKID),SUM(NVL(ESTMT VAR COST.ESTMT VAR COST AM 
7,0)) 


OVER(PARTITION BY ACTVY MTH GTIN.ACTVY SKID)),0,ACTVY MTH GTIN.MANUL COST OVRRD AMT * 
BRAND MTH RATE,ACTVY MTH GTIN.MANUL COST OVRRD AMT * 
NVL(DECODE(ACTVY.CORP PRMTN TYPE CODE,'Annual Agreement',AA.ESTMT VAR COST AMT, 

ESTMT VAR COST.ESTMT VAR COST AMT),0) /DECODE(ACTVY.CORP PRMTN TYPE CODE, 

'Annual Agreement',SUM(NVL(AA.ESTMT VAR COST AMT,0)) 

OVER(PARTITION BY ACTVY MTH GTIN.ACTVY SKID),SUM(NVL(ESTMT VAR COST.ESTMT VAR COST AM 
T,0)) 

OVER(PARTITION BY ACTVY MTH GTIN.ACTVY SKID)))),0),7) AS MANUL COST OVRRD AMT 

FROM OPT ACTVY DIM ACTVY, OPT _ PRMTN DIM PRMTN, OPT CAL MASTR DIM CAL, 

(SELECT ACTVY. ACTVY | SKID, ACTVY ! GTIN BRAND.ACTVY ID,ACTVY.FUND | SKID, 

ACTVY. ACCT PRMTN SKID AS ACCT SKID, ACTVY GTIN BRAND. PROD SKID, АСТУҮ GTIN BRAND.PROD ID, 
ACTVY GTIN BRAND.PRMTN SKID,ACTVY.BUS UNIT SKID,ACTVY GTIN BRAND.MTH SKID, 

ACTVY GTIN BRAND.FY DATE SKID,ACTVY.VAR COST ESTMT AMT AS ESTMT VAR COST, 
ACTVY.PRDCT FIXED COST AMT AS ESTMT FIX COST,ACTVY.CALC INDEX NUM AS ACTL FIX COST, 
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ACTVY.ACTL VAR COST NUM AS ACTL VAR COST,ACTVY.ESTMT COST OVRRD AMT,ACTVY.MANUL COST 
OVRRD AMT, 

ACTVY GTIN BRAND.ACTVY GTIN ACTL WGHT RATE,ACTVY GTIN BRAND.ACTVY GTIN ESTMT WGHT RATE, 
ACTVY GTIN BRAND.BRAND MTH RATE FROM OPT ACTVY FCT ACTVY, 

OPT _ACTVY _GTIN BRAND . SFCT ACTVY | GTIN BRAND, ОРТ ACCT DIM АССТ 

WHERE ACTVY. ACTVY SKID - ACTVY GTIN _BRAND.ACTVY . “SKID AND ACCT: ACCT SKID = ACTVY.ACCT_ 
PRMTN_SKID 

-- Optimall, B018, 9-Oct-2010, Kingham, filter out TSP account 

AND ACCT.FUND FRCST MODEL DESC not like 'TSP$') ACTVY МТН GTIN, 

--Estamate variable cost aggregated to brand level 

(SELECT Е5ТМТ.АСТУҮ ID А5 ACTVY ID,BRAND HIER.BRAND ID AS PROD ID, 

ESTMT.DATE SKID AS DATE | SKID, ESTMT.BUS CONTE SKID AS BUS _UNIT _5КТр, 

SUM(ESTMT. ESTMT WAR | COST AMT) AS ESTMT VAR | COST AMT, 

SUM (ESTMT. REVSD | BPT COST АМТ) AS REVSD | ВРТ COST | АМТ 

FROM ОРТ ACTVY | GTIN  ESTMT | SFCT ESTMT, -- add by rita 

OPT _ PROD | BRAND , ASSOC DIM "BRAND _ HIER, CAL_MASTR_DIM CAL 

WHERE ESTMT. PROD ID = BRAND HIER. PROD_ID | AND ESTMT. DATE SKID = CAL.CAL MASTR SKID 
AND CAL.FISC ҮК. SKID - BRAND | HIER.FY DATE , SKID GROUP BY  ESTMT. ACTVY ID, 

BRAND HIER. BRAND _ ID,ESTMT. DATE _ SKID, ESTMT. .BUS | UNIT SKID) ESTMT VAR COST, 

--Revised variable cost aggregated to brand level 

(SELECT REVSD.ACTVY ID AS ACTVY ID,BRAND HIER.BRAND ID AS PROD ID, 

REVSD.DATE SKID AS DATE SKID,REVSD.BUS UNIT SKID AS BUS UNIT SKID, 
SUM(REVSD.REVSD ESTMT VAR COST AMT) AS REVSD ESTMT VAR COST AMT 

FROM ОРТ ACTVY GTIN REVSD SFCT REVSD,OPT PROD BRAND ASSOC DIM BRAND HIER, 

CAL | MASTR - DIM CAL WHERE REVSD. PROD ID = - BRAND - HIER. PROD_ ID 

AND REVSD. .DATE | SKID = CAL.CAL MASTR | SKID AND CAL. FISC ҮК. SKID - BRAND HIER.FY DATE SKID 
GROUP BY REVSD. ACTVY ID, 

BRAND HIER.BRAND ID,REVSD.DATE SKID,REVSD.BUS UNIT SKID) REVSD VAR COST, 

--AA Variable Cost aggregated to Brand Level 

(SELECT АА.АСТУҮ ID AS ACTVY ID,BRAND HIER.BRAND ID AS PROD ID,AA.MTH SKID AS DATE S 
KID, 

AA.BUS UNIT SKID AS BUS UNIT SKID,SUM(AA.ESTMT VAR COST AMT) AS ESTMT VAR COST AMT, 
SUM(AA.REVSD VAR ESTMT COST AMT) AS REVSD ESTMT VAR COST AMT FROM OPT ACTVY BUOM GTIN 
.COST TFADS AA, 

OPT PROD BRAND ASSOC DIM ОРЫП WHERE AA.BUOM GTIN PROD SKID = BRAND HIER.PROD SKID 
AND BRAND HIER.FY DATE SKID = AA.FY DATE SKID GROUP BY AA.ACTVY ID, 

BRAND HIER. BRAND ID, AA. MTH SKID,AA. BUS | UNIT | SKID) АА 

WHERE ACTVY MTH | GTIN. ACTVY ` ID = ESTMT ' VAR | COST.ACTVY | XD(t) 

AND ACTVY | MTH | GTIN. MTH | SKID = ESTMT ' VAR | COST.DATE | SKID(*) 

AND ACTVY | MTH | GTIN. PROD ID = ESTMT VAR | COST.PROD | ID(*) 

AND ACTVY | MTH | GTIN. ACTVY ID = REVSD ` VAR | COST.ACTVY | ID(*) 

AND ACTVY MTH GTIN.MTH SKID = REVSD VAR COST.DATE SKID(*) 

AND ACTVY MTH GTIN.PROD ID = REVSD VAR COST.PROD ID(4) 

AND ACTVY МТН GTIN.ACTVY ID = AA.ACTVY ID(*) 

AND ACTVY MTH GTIN.MTH SKID = AA.DATE SKID(*) 

AND ACTVY МТН GTIN.PROD ID = AA.PROD Ір(+) 

AND ACTVY MTH GTIN.ACTVY SKID = ACTVY.ACTVY SKID 

AND ACTVY MTH GTIN.PRMTN SKID = PRMTN.PRMTN SKID 

AND ACTVY MTH GTIN.MTH SKID - CAL.CAL MASTR SKID)) 


SQL 的 执行 计划 如 下 (为 了 方便 排版 ， 我 们 删除 了 部 分 无 关 紧要 的 信息 )。 


SQL» select * from table(dbms xplan.display); 


PLAN TABLE OUTPUT 


Plan hash value: 2005223222 


| Id |Орегағіоп | Name |Rows | 
| 0 |SELECT STATEMENT | | 1| 
| 1 | VIEW | | 1| 
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2 | WINDOW BUFFER | 1 
|723 VIEW | 1 
| 4 WINDOW SORT | 1 
k 5 NESTED LOOPS | 

6 NESTED LOOPS 1 

7 NESTED LOOPS 1 

B HASH JOIN OUTER 1 
* 9 HASH JOIN OUTER 1 
XT) HASH JOIN OUTER 1 
*T3 4 HASH JOIN 1 
ias vl NESTED LOOPS 
13 NESTED LOOPS 1 
|*14 HASH JOIN 1 
I8 PARTITION LIST ALL 1 
[5I TABLE ACCESS FULL OPT ACCT DIM 1| 
17 PARTITION LIST ALL | 114K 
18 TABLE ACCESS FULL OPT ACTVY FCT | 114К| 
*19 INDEX RANGE SCAN OPT ' ACTVY | DIM PK 1 
20 TABLE ACCESS BY GLOBAL INDEX ROWID ОРТ ACTVY DIM ` 1 
ӘЛІ" | PARTITION LIST ALL 19M 
22 | TABLE ACCESS FULL OPT ACTVY GTIN BRAND SFCT 19M 
23 ] VIEW 1 
| 24 HASH GROUP BY 1 
25 NESTED LOOPS 
26 NESTED LOOPS 1| 
27 TABLE ACCESS FULL OPT ACTVY BUOM GTIN COST TFADS 1 
*28 INDEX RANGE SCAN OPT PROD BRAND ASSOC DIM PK 1| 
29 TABLE ACCESS BY GLOBAL INDEX ROWID|OPT PROD BRAND ASSOC DIM | + 
30 VIEW | 718 
эй | НА5Н ОВООР ВҮ | |на LS 
*32 (| HASH JOIN 718 
|9523 HASH JOIN 872 
| 34 PARTITION LIST ALL 872 
35 TABLE ACCESS FULL OPT ACTVY GTIN REVSD SFCT 872 
36 TABLE ACCESS FULL ОРТ | ' CAL | MASTR | DIM 36826 
37 PARTITION LIST ALL 671K 
38 TABLE ACCESS FULL |OPT PROD BRAND ASSOC DIM | 671&K| 
39 | VIEW | 6174 
| 40 HASH GROUP BY 6174 
|*41 HASH JOIN 6174 
*42 HASH JOIN 8998 
43 PARTITION LIST ALL 8998 
44 TABLE ACCESS FULL OPT ACTVY GTIN ESTMT SFCT 8998 
45 | TABLE ACCESS FULL OPT CAL MASTR DIM 36826 
46 | PARTITION LIST ALL 671К 
47 | TABLE ACCESS FULL |OPT PROD BRAND ASSOC DIM 671K| 
48 TABLE ACCESS BY INDEX ROWID OPT CAL MASTR DIM | 1 
*49 INDEX UNIQUE SCAN OPT CAL MASTR DIM PK i 
[*50 INDEX RANGE SCAN OPT ` PRMTN | DIM | PK 1 
51 TABLE ACCESS BY GLOBAL INDEX ROWID OPT ` PRMTN | DIM 1 





Predicate Information (identified by operation id): 


8 - aeccess("ACTVY GTIN BRAND"."ACTVY ID"-"ESTMT VAR COST"."ACTVY Тр" (+) AND 
"ACTVY GTIN BRAND"."MTH SKID"-"ESTMT VAR COST",."DATE SKID"(*) AND 
"ACTVY | GTIN BRAND"."PROD ID"-"ESTMT VAR . COST" , "PROD тр" (+)) 
Si es access ("ACTVY | GTIN  BRAND"."ACTVY ID"-"REVSD | VAR COST"."ACTVY Ір" (+) AND 
"ACTVY GTIN BRAND"."MTH SKID"-"REVSD ` VAR | COST"."DATE SKID™ (+) AND 
"ACTVY GTIN BRAND"."PROD ID"-"REVSD VAR | COST" . "PROD | ID"(4)) 
10 - access("ACTVY GTIN BRAND"."ACTVY ID"-"AA". "ACTVY ID" (+) AND 


276 


该 SQL 是 用 来 做 数据 清洗 的 (ETL)， 需 要 处 理 大 量 数据 。 处 理 大 量 数据 应 该 走 HASH Ж 


9.28 利用 等 待 事件 优化 SQL 


"ACTVY GTIN BRAND"."MTH SKID"-"AA"."DATE SKID" (+) AND 
"ACTVY GTIN | BRAND". "PROD Ір"="АА"."РКОр тр" (+) ) 
- access ("АСТҮҮ". "ACTVY SKID"= "ACTVY | GTIN BRAND","ACTVY. SKID") 


= access ("ACCT"."ACCT | SKID"-"ACTVY". 


"АСОТ. PRMTN SKID") 


- filter("ACCT"."FUND FRCST MODEL DESC" NOT LIKE 'TSP$') 

- access ("ACTVY"."ACTVY SKID"-"ACTVY"."ACTVY SKID") 

- access("AA"."BUOM GTIN PROD SKID"-"BRAND HIER"."PROD SKID" AND 
"BRAND HIER"."FY DATE SKID"-"AA"."FY DATE SKID") 

- access("REVSD"."PROD ID"-"BRAND HIER"."PROD ID" AND 
"CAL"."FISC YR SKID"-"BRAND HIER"."FY DATE SKID") 

- access("REVSD"."DATE SKID"-"CAL"."CAL MASTR SKID") 

- access("ESTMT"."PROD ID"-"BRAND HIER"."PROD ID" AND 
"CAL"."FISC YR SKID"-"BRAND HIER"."FY DATE SKID") 

- access("ESTMT"."DATE SKID"-"CAL"."CAL MASTR SKID") 

- access("ACTVY GTIN BRAND"."MTH SKID"-"CAL"."CAL MASTR SKID") 

- access("ACTVY GTIN BRAND"."PRMTN SKID"-"PRMTN"."PRMTN SKID") 


Bo АЕ ӘМТИ МІНДІМ, РИТИ ACER CES ORAT. 


注意 观察 执行 


本 计划， 执行 计划 中 14-16 和 Id=27 优化 器 评估 只 返回 1 


行 数据 ， 因 此 怀疑 


ОРТ ACCT DIM 和 ОРТ ACTVY BUOM GTIN COST TFADS 这 两 个 表 统 计 信息 有 问题 。 
对 这 两 个 表 收 集 完 统计 信息 之 后 ， 我 们 再 来 看 一 下 执行 计划 。 


SQL» select * from table (dbms xplan.display); 


PLAN 


Plan 


| TABLE OUTPUT 


hash value: 183294992 


|SELECT STATEMENT 

| VIEW 

| WINDOW BUFFER 

| VIEW 

| WINDOW SORT 

| HASH JOIN 

| PARTITION LIST ALL 

| TABLE ACCESS FULL 

| HASH JOIN 

| TABLE ACCESS FULL 

| HASH JOIN RIGHT OUTER 
| VIEW 

| HASH GROUP BY 

| HASH JOIN 

| HASH JOIN 

| PARTITION LIST ALL 
| TABLE ACCESS FULL 
| TABLE ACCESS FULL 
| PARTITION LIST ALL 
| TABLE ACCESS FULL 
| HASH JOIN RIGHT OUTER 
| УТЕЙ 

| HASH GROUP BY 

| HASH JOIN 

| HASH JOIN 

| PARTITION LIST ALL 
| TABLE ACCESS FULL 
| TABLE ACCESS FULL 


OPT_PRMTN_DIM 


ОРТ CAL MASTR DIM 


|OPT ACTVY GTIN ESTMT SFCT 
|OPT CAL MASTR DIM 

| 
|OPT_PROD_BRAND_ASSOC_DIM 
| 


|OPT ACTVY GTIN REVSD SFCT 
|OPT CAL MASTR DIM 


137880| 
| 19М| 
|36826| 
| 19М| 
| 6174| 
| 6174| 
| 6174| 
| 8998| 
| 8998 | 
| 8998 | 
136826| 
| 671K| 
| 671K| 
| 19M| 
|. 7181 
| 7161 
| 718| 
| 872] 
| 872] 
| 872] 
136826| 
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жаш» 

















SQL 优化 案例 赏析 

| PARTITION LIST ALL | 671K| 
| TABLE ACCESS FULL |OPT PROD BRAND ASSOC DIM | 671K| 
| HASH JOIN RIGHT OUTER | 19M| 
VIEW | 1| 
HASH GROUP BY 1| 

NESTED LOOPS | 
| NESTED LOOPS | 1| 
TABLE ACCESS FULL ОРТ ACTVY BUOM GTIN COST TFADS 11 
INDEX RANGE 5САМ OPT PROD BRAND ASSOC DIM PK | 11 
TABLE ACCESS BY GLOBAL INDEX ROWID|OPT PROD BRAND ASSOC DIM 11 
| НА5Н JOIN | 19M| 
| HASH JOIN | | 114K| 
| PARTITION LIST ALL | 115K| 
TABLE ACCESS FULL OPT ACTVY DIM | 115K| 
| HASH JOIN | | 114K| 
| PARTITION LIST ALL | 1944781 
| TABLE ACCESS FULL |OPT ACCT DIM | 94478 | 
| PARTITION LIST ALL | | 114K| 
| TABLE ACCESS FULL |OPT ACTVY FCT | 114K| 
| PARTITION LIST ALL | | 19M] 
| TABLE ACCESS FULL |OPT ACTVY GTIN BRAND SFCT | 19м| 


access("ACTVY GTIN BRAND"."PRMTN SKID"-"PRMTN"."PRMTN SKID") 

access ("АСТУҮ GTIN | | BRAND" , "MTH | SKID"- "CAL"."CAL MASTR SKID") 

access("ACTVY GTIN | BRAND". "ACTVY ` ID"-"ESTMT VAR ! | COST". "ACTVY TID" (+) 
AND "ACTVY | GTIN BRAND". "MTH | SKID"-"ESTMT " VAR COST", "DATE | SKID"(*) AND 
"ACTVY | GTIN | BRAND". "PROD ID"-"ESTMT VAR ! cosT". "PROD тр" (+)) 

access ("ESTMT". "PROD_ID"= "BRAND HIER". "PROD ID" AND 
"CAL","FISC YR SKID"-"BRAND HIER"."FY DATE SKID") 

access("ESTMT",."DATE SKID"-"CAL"."CAL MASTR SKID") 

access("ACTVY GTIN BRAND"."ACTVY Ір"= "REVSD ` | VAR COST"."ACTVY Ір" (+) 
AND "ACTVY 1 GTIN BRAND". "MTH | SKID"-"REVSD | VAR COST", "DATE |, SKID"(*) AND 
"ACTVY GEIN- BRAND". "PROD тр"= "REVSD VAR | COST". "PROD ID"(4)) 

access ("REVSD". "PROD ID"- "BRAND | HIER". "PROD _ ID" AND 
POAR. SPISE 1 ҮЙ SKID"= "BRAND | HIER". NES DATE SKID") 

access ("REVSD"."DATE | SKID's"CAL","CAL _ MASTR | SKID") 

access("ACTVY GTIN | BRAND". "АСТУҮ Ір"= "AA"."ACTVY  ID"(*) AND 
"ACTVY GTIN | BRAND". "МІН. SKID"-"AA"."DATE | SKID" (+) AND 
"ACTVY | GTIN | BRAND". "PROD ID"-"AA","PROD-. ID" (+)) 

access ("AA". "BUOM | GTIN PROD . SKID"- "BRAND HIER"."PROD SKID" AND 
"BRAND | HIER". "FY_ DATE |. SKID"-"AA", "ту, DATE | SKID") 

access ("ACTVY" , "ACTVY | SKID"- "ACTVY | GTIN | BRAND" . "ACTVY КІП") 

access ("ACTVY". "ACTVY SKID"- "ACTVY". "ACTVY SKID") 

access("ACCT"."ACCT SKID"-"ACTVY"."ACCT PRMTN SKID") 

filter("ACCT"."FUND FRCST MODEL DESC" NOT LIKE 'TSP$') 


执行 计划 中 ， 除 了 14-35 和 Id=37 两 个 表 没 有 走 HASH 连接 之 外 ， 其 余 表 都 走 了 HASH 
连接 。Id=35 的 表 OPT ACTVY BUOM GTIN COST TFADS 之 前 已 经 收集 过 统计 信息 ， 
此 Id=35 和 Id=37 的 表 走 嵌 套 循环 没有 问题 , 那么 整个 SQL 的 执行 计划 现在 是 正确 的 。 纠 正 
完 执 行 计划 之 后 ， 笔 者 将 SQL 放 在 后 台 运 行 了 大 概 两 小 时 ， 发 现 SQL 还 没 执行 完毕 。 起 初 ， 
笔者 认为 SQL 执行 7 ae сизо L: SQL 执行 计划 错误 导致 的 ,但 是 现在 纠正 了 SQL 
的 执行 计划 ，SQL 执行 了 两 小 时 还 是 没有 跑 完 ， 于 是 监控 SQL 的 等 待 事件 ， 看 SQL 究竟 在 
等 什么 。 





9.28 利用 等 待 事件 优化 SQL 


SQL» select inst id,sid,serial#,event,pl,p2,p3 
2 from gv$session where osuser-'luobi'; 


INST ID SID SERIAL4 EVENT Pl. P2 P3 
prx 2 4754 10050 direct path write temp 20025 857328 7 
SQL» / 

INST ID SID SERIAL4 EVENT PI P2 P3 
rer 2. 4194 10050 dixect path write temp 20025. 406768 | 7 
SQL» / 

INST ID SID SERIAL# EVENT P1 P2 P3 
44 6; 2 7474 10050 direct path write temp 20007 28492646 ~ 7 
SQL> / 

INST ID SID SERIAL4 EVENT Р1 Р2 РЗ 
adi 2 4154 10050 direct path write temp 20007 1153424 7 
SOL» / 

INST ID SID SERIAL# EVENT P1 P2 P3 
P a 2 . 4754 у, 10050 direct path write temp, 2.420002 , 91029 . 17 


我 们 监控 到 该 SQL 的 等 待 事件 为 direct path write temp， 该 等 待 事 件 表示 当前 SQL 正在 进 
行 排序 或 者 正在 进行 HASH 连接 ， 但 是 因为 PGA 不 够 大 ， 不 能 完全 容纳 需要 排序 或 者 需要 
HASH 的 数据 ， 导 致 有 部 分 数据 被 号 入 temp 表 空 间 。 

为 了 追查 究竟 是 因为 排序 还 是 因为 HASH 而 引发 的 direct path write temp 等 待 ， 使 用 以 下 
脚本 查看 临时 段 数据 类 型 。 


SQL» select a.inst id, a.sid, а.зегіа1%, a.sqgl id, b.tablespace, b.blocks* 

2 (select value from v$parameter where name-'db block size')/1024/1024 "Size(M)",b 
.segtype 

3 from gv$session a, gv$tempseg usage b where a.inst id-b.inst id and a.saddr = b. 
session addr 

4 and a.inst id-2 and a.sid-4754; 


INST ID SID SERIAL# SQL ID TABLESPACE Size(M) SEGTYPE 
2 4754 10050 6qsuc8mafy20m TEMP 1 DATA 
2 4754 10050 6qsuc8mafy20m TEMP 1 LOB DATA 
2 4754 10050 6qsuc8mafy20m TEMP 1 INDEX 
2 4754 10050 6qsuc8mafy20m TEMP 1 LOB DATA 
2 4754 10050 6qsuc8mafy20m TEMP 3304 HASH 


从 SQL 查询 中 我 们 看 到 ， 临 时 段 数 据 类 型 为 HASH， 耗 费 了 3 304MB 的 temp 表 空 间 ， 
这 表示 SQL 是 因为 HASH 连接 引发 的 direct path write temp 等 待 。 

大 家 请 仔细 观察 等 待 事件 P3， 它 的 值 一 直 为 7， 这 表示 Oracle 一 次 只 写 入 7 个 块 到 temp 
表 空 间 ， 而 且 是 一 直 只 写 入 7 个 块 到 temp 表 空 间 。 笔 者 在 第 4 章 中 讲 到 ， 绝 大 多 数 的 操作 系 
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统 , 一 次 VO 最 多 只 能 读 取 或 者 写 入 IMB 数据 。 这 里 的 数据 块 大 小 为 16KB， 正常 情况 下 应 该 
是 每 次 VO 写 入 64 个 块 到 temp 表 空 间 , 但 是 每 次 IO 只 写 了 7 个 块 。 于 是 怀疑 是 PGA 中 work 
area 不 够 导致 出 现 了 该 问题 。 
РСА 在 自动 管理 的 情况 下 ， 单 个 PGA 进程 的 work area 不 能 超过 1GB( 想 要 超过 1GB 需 
要 修改 隐 仿 参数， 但 是 本 书 主题 是 SQL 优化 ， 因 此 不 想 太 多 涉及 到 Oracle 内 部 原理 )， 如 果 
PGA 是 手动 管理 ， 单 个 PGA 进程 的 work area 可 以 接近 2GB， 但 是 不 能 超过 2GB。 
SQL» alter session set workarea size policy = manual; 


Session altered. 


SQL» alter session set hash area size - 2147483648; ---2GB 


alter session set hash area size = 2147483648 
* 


ERROR at line 1: 
ORA-02017: integer value required 


SQL» alter session set hash area size = 2147483647; 


Session altered. 


将 РСА 的 work area 设置 为 接近 2GB 之 后 ， 重 新 运行 了 SQL 并 且 监 控 等 待 事件 。 


SQL» select inst id,sid,serial#,event,pl,p2,p3 
2 from gv$session where osuser-'luobi'; 


INST ID SID SERIAL# EVENT Pl P2 P3 


2 4885 11759 direct path write temp 20012 71053 64 


将 PGA 的 work area 设置 为 接近 2GB 之 后 ， 笔 者 发 现 РЗ 可 以 达到 64， 相 比 之 前 一 次 只 
能 写 入 7 个 块 速度 提升 了 9 fi. 

有 direct path write temp 等 待 必 然 会 出 现 direct path read temp 等 待 , 在 没 修改 PGA 的 work 
area 之 前 ， 不 仅仅 是 单 次 IO 只 能 写 入 7 个 块 ， 单 次 1/O 读 取 也 是 只 能 读 取 7 个 块 ， 因 此 ， 将 
РСА 的 work area 设置 为 接近 2GB 之 后 ， 整 个 SQL 的 性 能 应 该 提升 了 18 倍 。 

最 后 ， 经 过 对 比 测试 ， 手 动 设置 work area 的 SQL 只 需要 56 分 钟 左 右 就 能 执行 完毕 。 


6889440 rows selected. 


Elapsed: 00:56:36.08 


而 自动 work area 管理 的 SQL 还 在 一 直 等 待 direct path write temp, НИЯ SQL 如 果 不 手 
动 设置 work area 可 能 跑 一 天 一 夜 都 跑 不 完 。 

优化 完 上 述 SQL 之 后 ,我 们 发 现 当时 整个 平台 已 经 竣 痪 ,整个 平台 都 出 现 了 了 P3=7 的 问题 ， 
最 后 经 过 与 Oracle 确认 ， 发 现 该 问题 是 11.1.0.7 版 本 在 HPUX 平台 下 的 一 个 bug。Oracle 开发 
补丁 需要 一 定 的 时 间 ， 在 此 期 间 , 使 用 本 书 给 出 的 方法 临时 解决 了 项 目 中 过 到 的 问题 , 确保 项 
目 不 会 因此 延期 。 "I 


第 10 章 全 自动 SQL 审核 


本 章 ， 我 们 为 大 家 分 享 一 些 常用 的 全 自动 SQL 审核 脚本 ， 在 实际 工作 中 ， 我 们 可 以 对 肢 
本 进行 适当 修改 ， 以 便 适应 自己 的 数据 库 环境 ， 从 而 提升 工作 效率 。 因 为 本 书 的 主题 是 SQL 
优化 ， 所 以 本 章 不 会 涉及 常用 的 数据 库 监控 脚本 和 常用 的 ОВА 运 维 脚本 。 


此 脚本 不 依赖 统计 信息 。 
建议 在 外 键 列 上 创建 索引 ， 外 键 列 不 创建 索引 容易 导致 死 锁 。 级 联 删 除 的 时 候 ， 外 键 列 没 
有 索引 会 导致 表 被 全 表 扫 描 。 以 下 脚本 抓 出 Scott 账户 下 外 键 没 创 建 索引 的 表 。 


with cons as (select /*+ materialize */ owner, table name, constraint name 
from dba constraints 
where owner - 'SCOTT' 
AND constraint type - 'R'), 
idx as ( 
select /*+ materialize */ table owner,table name, column name 
from dba ind columns 
where table owner - 'SCOTT') 
select owner,table name,constraint name,column name 
from dba cons columns 
where (owner,table name, constraint name) in 
(select * from cons) 
and (owner,table name, column name) not in 
(select * from idx); 


在 Scott 账户 中 ，EMP 表 的 deptno 列 引 用 了 DEPT 表 的 deptno 列 ， 但 是 没有 创建 索引 ， 
因此 我 们 通过 脚本 可 以 将 其 抓 出 。 


SOL> with cons as (select /*+ materialize */ owner, table name, constraint_name 
2 from dba constraints 









3 where owner = 'SCOTT' 
4 AND constraint type = 'R'), 
5 idx as ( 
6 select /%% materialize */ table owner,table name, column name 
7 from dba ind columns 
8 where table owner = 'SCOTT') 
9 select owner,table name,constraint name,column name 
10 from dba cons columns 
11 where (owner,table name, constraint_name) іп 
12 (select * from cons) 
13 and (owner,table name, column name) not in 
14 (select * from idx); 
OWNER TABLE NAME CONSTRAINT NAME COLUMN NAME 


SCOTT EMP FK DEPTNO DEPTNO 






102) n | 


此 脚本 依赖 统计 信息 。 

当 一 个 表 比 较 大 ， 列 选择 性 低 于 5%， 而 且 列 出 现在 where 条 件 中 ， 为 了 防止 优化 器 估算 
Rows 出 现 较 大 偏差 ， 我 们 需要 对 这 种 列 收 集 直 方 图 。 以 下 脚本 抓 出 Scott 账户 下 ， 表 总 行 数 
大 于 5 万 行 、 列 选择 性 低 于 5% 并 且 列 出 现在 where 条 件 中 的 表 以 及 列 信息 。 


select a.owner, 
a.table_name, 
a.column name, 
b.num rows, 
a.num distinct Cardinality, 
round(a.num distinct / b.num rows * 100, 2) selectivity 
from dba tab col statistics a, dba tables b 
where a.owner — b.owner 
and a.table name = b.table name 
and a.owner = 'SCOTT' 
and round(a.num distinct / b.num rows * 100, 2) < 5 
and num rows » 50000 
and (a.table name, a.column name) in 
(select o.name, c.name 
from sys.col usage$ u, sys.obj$ o, sys.col$ c, sys.user$ г 


where o.obj# = u.obj# 
and c.obj# = u.obj# 5 
and с.со1% = u.intcol# 
and r.name = 'SCOTT'); 


在 Scott 账户 中 ，test 表 总 行 数 大 于 5 211, owner 列 选择 性 小 于 5%， 而 且 出 现在 where | 
条 件 中 ， 通 过 以 上 脚本 我 们 可 以 将 其 抓 出 。 x 
| 


SQL> select a.owner, 
2 a.table_name, 
3 a.column_name, 
4 b.num_rows, | 
5 a.num_distinct Cardinality, | 
6 round(a.num_distinct / b.num_rows * 100, 2) selectivity 
7 from dba tab col statistics a, dba tables b 
8 where a.owner - b.owner 

9 















and m b.table name 

10 and % | dum 

11 and round(a.num distinct / b.num rows * 100, 2) « 5 

12 and nt 15 > 50000 

13 апа (а. le name, a.column name) іп 

14 (select o.name, c.name | 

15 from sys.col usage$ u, sys.obj$ o, sys.col$ c, sys.user$ r 

16 where o.obj# = u.obj# 

17 and c.obj# = u.obj# 

18 and c.col# = u.intcol# 

19 and r.name = 'SCOTT'); 
OWNER TABLE NAME .. COLUMN NAME NUM ROWS CARDINALITY SELECTIVITY 
SCOTT TEST OWNER 73020 29 04 
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10.3 ” 抓 出 必须 创建 索引 的 列 





此 脚本 依赖 统计 信息 。 
当 一 个 表 比 较 大 ， 列 选择 性 超过 20%， 列 出 现在 where 条 件 中 并 且 没 有 创建 索引 ， 我 们 可 
以 对 该 列 创建 索引 从 而 提升 SQL 查询 性 能 。 以 下 脚本 抓 出 Scott 账户 下 表 总 行 数 大 于 5 万 行 、 
列 选择 性 超过 20%、 列 出 现在 where 条 件 中 并 且 没 有 创建 索引 。 


Select 


from 


where 
and 
and 


апа 


在 Scott 账户 中 ，test 表 总 行 数 


owner, 
table_name, 
column_name, 
num_rows, 
Cardinality, 
selectivity 
(select a.owner, 
a.table name, 
a.column name, 
b.num rows, 
a.num distinct Cardinality, 
round(a.num distinct / b.num rows * 100, 2) selectivity 
from dba tab col statistics a, dba tables b 
where a.owner = b.owner 
and a.table name = b.table name 
and a.owner - 'SCOTT') 
selectivity »- 20 
num rows » 50000 
(table name, column name) not in 
(select table name, column name 
from dba ind columns 
where table owner = 'SCOTT' and column position-1) 
(table name, column name) in 
(select o.name, c.name 
from sys.col usage$ u, Sys.obj$ o, sys.col$ c, sys.user$ r 










where o.obj# = u.obj# 
and c.obj# = u.obj# 
and c.col# = u.intcolf 
and r.name = END; 


20%， 而 且 没 有 创建 索引 ， 我 们 通过 以 上 脚本 将 其 抓 出 。 


SQL> select owner, 


ш № 


table name, 
column name, 
num rows, 
Cardinality, 
selectivity 
from (select a.owner, 
a.table name, 
a.column name, 
b.num rows, 
a.num distinct Cardinality, 


大 于 5 万 行 ， 有 两 个 列 出 现在 where 条 件 中 ， 


选择 性 大 于 


round(a.num_distinct / b.num_rows * 100, 2) selectivity 


from dba tab col statistics a, dba tables b 
where a.owner = b.owner 
and a.table name - b.table name 


and a.owner. 2 =! ^ xc 1 E 
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17 where 





and S ) 
and (table name, column name) not in 
(select table name, column name 
from dba ind columns 
where te 
and (table | name, 
(select o.name, c. name 
from sys.col usage$ u, sys.obj$ o, sys.col$ c, sys.user$ r 
where o.obj# = u.objt 









and c.obj# u.obj# 

and c. 'col# = u орсо 

and r.name = 
TABLE NAME NUM ROWS CARDINALITY SELECTIVITY 
TEST OBJECT ID 73020 73020 100 
TEST OBJECT NAME 73020 41002 55.15 





此 脚本 不 依赖 统计 信息 。 

在 开发 过 程 中 ， 我 们 应 该 尽量 避免 编写 SELECT * XF SQL. SELECT * 这 种 SQL， 走 
索引 无 法 避免 回 表 , 3E HASH 连接 的 时 候 会 将 驱动 表 所 有 的 列 放 入 PGA H, Wi PGA NF. 
执行 计划 中 (V$SQL PLAN/PLAN TABLE), projection 字段 表示 访问 了 哪些 字段 ， 如 果 
projection 字段 中 字段 个 数 等 于 表 的 字段 总 个 数 ， 那 么 我 们 就 可 以 判断 SQL 语句 使 用 了 
SELECT*。 以 下 脚本 抓 出 SELECT* 的 SQL. 


select a.sql id, a.sql_text, c.owner, d.table name, d.column cnt, c.size mb 


from 


where 
and 
and 
and 
and 
and 
and 
and 
order 


v$sqdl a, 
v$sql plan b, 


(select owner, segment name, sum(bytes / 1024 / 1024) size mb 
from dba segments 
group by owner, segment name) c, 
(select owner, table name, count(*) column cnt 
from dba tab cols 
group by owner, table name) d 
.841 id = b.sql id 
.child number = b.child number 
.орјесі owner = c.owner 


.object owner = d.owner 
.object name = d.table name 


a 
a 
b 
b.object name = c.segment name 
b 
b 


REGEXP COUNT (b.projection, ']') = d.column cnt 


c.owner = 'SCOTT' 


by 6 desc; 


我 们 在 Scott 账户 中 运行 如 下 SQL. 


| select 


* from t where object id«1000; 


我 们 使 用 脚本 将 其 抓 出 。 


SQL» select a.sql_id, a.sql_text, c.owner, d.table name, d.column cnt, c.size mb 


2 
3 


from v$sql а, 
v$sql plan b, 


^ ————— -————má 


10.5 抓 出 有 标量 子 查询 的 SQL 


4 (select owner, segment name, sum(bytes / 1024 / 1024) size mb 
5 from dba segments 

6 group by owner, segment name) c, 

7 (select owner, table name, count(*) column cnt 

8 from dba tab cols 

9 group by owner, table name) d 
10 


where a.sql іа = b.sql id 
11 and a.child number - b.child number 
12 and b.object owner = c.owner 
13 and b.object name - c.segment name 
14 and b.object owner - d.owner 
15 and b.object name = d.table name 
16 and REGEXP COUNT(b.projection, ']') = d.column cnt 
17 and c.owner - 'SCOTT' 


18 order by 6 desc; 


SQL ID SQL TEXT OWNER TABLE NAME COLUMN СМТ SIZE MB 
ga64bhp5fxhtn select * from t where object id«1000 SCOTT T 15 9 





此 脚本 不 依赖 统计 信息 。 

在 开发 过 程 中 ,我 们 应 该 尽量 避免 编写 标量 子 查询 。 我 们 可 以 通过 分 析 执 行 计 划 ， 抓 出 标 
量子 查询 语句 。 同 一 个 SQL 语句 ， 执 行 计划 中 如 果 有 两 个 或 者 两 个 以 上 的 depth-1 的 执行 计 
RIEZ SQL 中 出 现 了 标量 子 查 询 。 以 下 脚本 抓 出 Scott 账户 下 在 SQL*Plus 中 运行 过 的 标量 
子 查 询 语句 。 

select 591 id, sql text, module 

from v$sql 

where pe 

and : 

AND sql id in 

(select sql id 
from (select sql id, 
count(*) over(partition by sql id, child number, depth) cnt 


from V$SQL PLAN 
where depth 一 1 








ol or object_owner is null)) 
where cnt >= 2); 


我 们 在 SQL*Plus 中 运行 如 下 标量 子 查 询 语句 。 


SQL> "select dname, 
2 (select max(sal) from emp where deptno - d.deptno) max sal 
3 from dept d; 


DNAME MAX SAL 
ACCOUNTING 5000 
RESEARCH 3000 
SALES 2850 
OPERATIONS 


我 们 利用 以 上 脚本 将 刚 运行 过 的 标量 子 查 询 抓 出 。 


| SQL» select sql id, sql text, module 


285 


286 





2 from v$sql 

3 where parsing_schema_name = 'SCOTT' 

4 and module = 'SQL*Plus' 

5 AND sql_id in 

6 (select sql id 

7 from (select sql id, 

8 count(*) over(partition by sql id, child number, depth) cnt 
9 from V$SQL PLAN 

10 where depth = 1 

11 and (object owner = 'SCOTT' or object owner is null)) 
12 where cnt >= 2); 


SOL ID SQL TEXT MODULE 


739f£hcu0pbz28 select dname, (select max(sal) from emp where  SQL*Plus 
deptno = d.deptno) max sal from dept d 





此 脚本 不 依赖 统计 信息 。 
在 开发 过 程 中 ， 我 们 应 该 避免 在 SQL 语句 中 调用 自 定义 函数 。 我 们 可 以 通过 以 下 SQL 语 
ЖАЙТЫ SQL 语句 中 调用 了 自 定义 函数 的 SQL。 


select distinct sql id, sql text, module 

from V$SQL, 

(select object name 
from DBA HN S о 
where ОМ ETT gl 

and сете "сүре іп ('FUNCTION', 'PACKAGE')) 
where (instr(upper(sql text), object name) > 0) 

and plsql exec time > 0 

and regexp . like (upper (sql Еца бехе) vA [SELECT] ') 

and 


我 们 在 Scott T 中 创建 如 下 函数 。 


create or replace function f getdname(v deptno in number) return varchar2 as 
v dname dept.dname$type; 

begin 
select dname into v dname from dept where deptno - v deptno; 
return v dname; 

end f getdname; 

/ 


然后 我 们 在 Scott 账户 中 运行 如 下 SQL. 


SQL» select empno,sal,f getdname(deptno) dname from emp; 








EMPNO SAL DNAME 

7369 800 RESEARCH 
7499 1600 SALES 

7521 1250 SALES 

7566 2975 RESEARCH 
7654 1250 SALES 

7698 2850 SALES 

7782 2450 ACCOUNTING 
7788 3000 RESEARCH 


107 抓 出 表 被 多 次 反复 调用 SQL 


7839 5000 ACCOUNTING 
7844 1500 SALES 

7876 1100 RESEARCH 
7900 950 SALES 

7902 3000 RESEARCH 
7934 1300 ACCOUNTING 


我 们 通过 脚本 抓 出 刚 执 行 过 的 SQL 语句 。 


SOL» select distinct sql id, sql text, module 






2 from V$SQL, 

3 (select object name 

4 from DBA OBJECTS O 

5 where owner - 'SCOTT' 

6 and object type in ('FUNCTION', 'PACKAGE')) 

7 where (instr(upper(sql text), object name) > 0) 

8 and plsql exec time > 0 

9 and regexp like(upper(sql fulltext), '^[SELECT]') 

10 and parsing schema name - 'SCOTT'; 
SQL ID SQL TEXT MODULE 
2ck71xc69j49u select empno,sal,f getdname(deptno) dname from emp SQL*Plus 
此 脚本 不 依赖 统计 信息 。 


在 开发 过 程 中 ， 我 们 应 该 避免 在 同一 个 SQL 语句 中 对 同一 个 表 多 次 访问 。 我 们 可 以 通过 
下 面 SQL 抓 出 同一 个 SQL 语句 中 对 某 个 表 进 行 多 次 扫描 的 SQL. 


select a.parsing_schema_name schema, 
a.Sql id, 
a.sgl text, 
b.object name, 
b.cnt 
from v$sql a, 
(select * 
from (select sql id, 
child number, 
object owner, 
object name, 
object type, 
count(*) cnt 
from 
where С 
group by sql id, 
child number, 
object owner, 
object name, 
object type) 
where cnt »- 2) b 
where а.ѕ91 іа = b.sqgl id 
and a.child number - b.child number; 


我 们 在 Scott 账户 中 运行 如 下 SQL. 


| select ename,job,deptno from emp where sal»(select avg(sal) from emp); 
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XOU жазсақ” 


以 上 SQL 访问 了 emp 表 两 次 ， 我 们 可 以 通过 脚本 将 其 抓 出 。 


SQL» select a.parsing schema name schema, 


2 a. sql 34, 

3 а.в41 text, 

4 b.object name, 

5 b.cnt 

6 from v$sql a, 
7 (select * 
8 from (select sql id, 
9 child number, 

10 object owner, 

ЗЫ: object name, 

12 object type, 

13 count(*) cnt 

14 from v$sql plan 

15 where object owner - 'SCOTT' 
16 group by sql id, 

17 child number, 

18 object owner, 

19 object name, 

20 object type) 

21 where cnt »- 2) b 

22 where a.sql id = b.sgl id 

23 and a.child number - b.child number; 
SCHEMA SQL ID SQL TEXT OBJECT NAME CNT 
SCOTT fdt0z70z43vgv select ename,job,deptno from  EMP 2 


emp where sal»(select avg (sal) 
from emp) 






此 脚本 不 依赖 统计 信息 。 

当 where 子 查 询 没 能 unnest， 执 行 计划 中 就 会 出 现 FILTER， 对 于 此 类 SQL， 我 们 应 该 在 
上 线 之 前 对 其 进行 改写 ， 避 免 执行 计划 中 出 现 FILTER， 以 下 脚本 可 以 抓 出 where 子 查 询 没 能 
unnest 的 SQL。 


select parsing schema name schema, sql id, sql text 
from v$sql 
where parsing sch пате = 'SC 
апа (sql_id, ch | number) in 
(select sql id, child number 

from v$sql plan 








where operation - 'FILTER' 
and filter predicates like '$IS NOT NULLS' 
minus 


select sql id, child number 
from v$sql plan 
where object owner = 'SYS'); 


我 们 在 Scott 账户 中 运行 如 下 SQL 并 且 查 看 执行 计划 。 


SQL> select * 
2 from dept 
3 where exists (select null 


10.8 抓 出 走 了 FILTER 的 SQL 


4 from emp 

5 where dept.deptno - emp.deptno 

6 start with empno - 7698 

T connect by prior empno = mgr); 
DEPTNO DNAME LOC 


30 SALES CHICAGO 
Elapsed: 00:00:00.00 


Execution Plan 


Plan hash value: 4210865686 


| Мате | Rows | Bytes | Cost (%CPU) |Time | 





| | 到 | 20| 9 (0)100:00:01| 

FILTER | | | | | 
TABLE ACCESS FULL | DEPT | 4| 80| 3 (0) |00:00:01| 
|* 3| FILTER | | | | | | 
|* 4| CONNECT BY NO FILTERING WITH SW (UNIQUE) | | | | | | 
ү d] TABLE ACCESS FULL |EMP | 14| 154] 3 (0) 100:00:011 


Predicate Information (identified by operation id): 


1 - filter( EXISTS (SELECT 0 FROM "EMP" "EMP" WHERE "EMP"."DEPTNO"-:B1 START WITH 
"ЕМРМО"-7698 CONNECT BY "MGR"-PRIOR "EMPNO")) 
3 - filter("EMP"."DEPTNO"-:B1) 
4 - access("MGR"-PRIOR "EMPNO") 
filter("EMPNO"-7698) 


Statistics 
0 recursive calls 
0 db block gets 
36 consistent gets 
0 physical reads 
0 redo size 
550 bytes sent via SQL*Net to client 
419 bytes received via SQL*Net from client 
2 SQL*Net roundtrips to/from client 
8 sorts (memory) 
0 sorts (disk) 
1 rows processed 


以 上 SQL 执行 计划 中 出 现 了 FILTER， 我 们 通过 脚本 抓 出 走 了 FILTER 的 SQL. 


SQL> select parsing schema name schema, sql id, sql text 

2 from v$sql 

3 where parsing schema name = 'SCOTT' 

4 and (sql id, child number) in 

5 (select sql id, child number 

6 from v$sql plan 

7 where operation = 'FILTER' 

8 and filter predicates like '$IS NOT NULL$' 
8 minus 

0 


1 select sgl id, child number 
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pe eem 


11 from у$за1_р1ап 
12 where object owner = "5Ү5"); 
SCHEMA SQL ID SQL TEXT 
SCOTT 8rmn2fnl49y2z select * from dept where exists (select null from emp 
where dept.deptno - emp.deptno start with em 
pno = 7698 connect by prior empno = mgr) 






10.9} 


此 脚本 不 依赖 统计 信息 。 

两 表 关 联 返 回 少量 数据 应 该 走 嵌 套 循环 ， 如 果 返 回 大 量 数据 ， 应 该 走 HASH 连接 ， 或 者 
是 排序 合并 连接 。 如 果 一 个 SQL 语句 返回 行 数 较 多 (大 于 1 万 行 》 SQL 的 执行 计划 在 最 后 几 
步 (Id<=5) E T CES АЯ, 我们 可 以 判定 该 执行 计划 中 的 稀 套 循环 是 有 问题 的 , 应 该 走 HASH 
连接 。 以 下 脚本 抓 出 返回 行 数 较 多 的 嵌 套 循环 SQL. 


select * 
from (select parsing schema name schema, 
sql id, 
sql text, 


rows processed / executions rows processed 
from v$sql 
where parsing schema name - 'SCOTT' 
and executions » 0 
and rows processed / executions » 10000 
order by 4 desc) a 
where a.sql id in (select sql id 
from v$sql plan 
where operation like '$NESTED 100Р5%" 
and id «- 5); 


在 scott 账户 中 分 别 创建 a KA b 表 以 及 一 个 索引 。 
SQL» create table a as select * from dba objects; 
Table created. 
SQL» create table b as select * from dba objects; 
Table created. 
SOL» create index idx b on b(object id); 
Index created. 
运行 如 下 SQL 并 且 查 看 执行 计划 。 
SQL» select /*+ use nl(a,b) */ * from a,b where a.object id-b.object id; 
72695 rows selected. 


Execution Plan 


Plan hash value: 2104163270 


10.9 НЕН AREA SQL 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)| Time | 
| 0 | SELECT STATEMENT | | 60140 | 23М| 120K (1)| 00:24:07 | 
| 1 | NESTED LOOPS | | | | | | 
| l NESTED LOOPS | | 60140 | 23M| 120K (1)| 00:24:07 | 
NE TABLE ACCESS FULL | A | 60140 | 11M| 187 (2)1 00:00:03 
1*4 | INDEX RANGE SCAN | IDX B | 1 | І 1 (0) | 00:00:01 | 
| 2S6] TABLE ACCESS BY INDEX ROWID| B | 1 | 204. | 2 (0)1 00:00:01 | 
Predicate Information (identified by operation id): 
4 = access("A","OBJECT ID"-—"B","OBJECT ID") 
Note 
- dynamic sampling used for this statement (level-2) 
Statistics 
632 recursive calls 
0 db block gets 
22985 consistent gets 
1196 physical reads 
0 redo size 
6085032 bytes sent via SQL*Net to client 
53725 bytes received via SQL*Net from client 
4848 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
72695 rows processed 
RATE AE АЖ EE CUAL o 
SQL» select * 
2 from (select parsing schema name schema, 
3 sql id, 
4 sql text, 
5 rows processed / executions rows processed 
6 from v$sql 
7 where parsing schema name - 'SCOTT' 
8 and executions > 0 
9 and rows processed / executions » 10000 
10 order by 4 desc) a 
11 where a.sql id in (select sql id 
12 from v$sql plan 
13 where operation like '$NESTED ІООР5%" 
14 and id <= 5); 
SCHEMA SQL ID 501 TEXT ROWS PROCESSED 
SCOTT 4dwp5u34yv'7mj select /*+ use nl(a,b) */ * 72695 


from a,b where a.object id-b.object id 
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此 脚本 不 依赖 统计 信息 。 
嵌 套 循环 的 被 驱动 表 应 该 走 索 引 ， 以 下 脚本 抓 出 稀 套 循环 被 驱动 表 走 了 全 表 扫 描 的 SQL, 
同时 根据 表 大 小 降序 显示 。 


select с.за1 text, a.sql id, b.object name, d.mb 
from v$sql plan а, 
(select * 
from (select sql id, 
child number, 
object owner, 
object name, 
parent id, 





operation, 
options, 
row number() over(partition by sql id, child number, parent id 
order by id) rn 
from v$sql plan) 
where rn - 2) b, 
v$sql c, 
(select owner, segment name, sum(bytes / 1024 / 1024) mb 
from dba segments 
group by owner, segment name) d 
where b.sgl id = свай id 
and b.child number - c.child number 
and b.object owner - 'SCOTT' 
and a.sql id = b.sql id 
and a.child number - b.child number 
and a.operation like '$NESTED LOOPS$' 


and 
and 
and 


a.id - b.parent id 
b.operation 'TABLE ACCESS' 
b.options ' FULL' 


and b.object owner = d.owner 
and b.object name = d.segment name 
order by 4 desc; 


我 们 在 Scott 账户 中 运行 如 下 SQL. sul ЖЕШ НК, ОИ ЕЕ 4 Ka. 


select /*+ use nl(a,b) full(a) full(b) */ * 
from a, b 
where a.object id - b.object id; 


我 们 通过 以 上 脚本 将 其 抓 出 。 


SQL» select c.sql_text, a.sql_id, b.object name, d.mb 


2 from v$sql plan a, 

3 (select * 

4 from (select 591 id, 

5 child number, 
6 object owner, 
7 object name, 
8 parent id, 

9 operation, 
10 options, 
11 


nt jd order by id) rn 
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row number() over(partition by sql id, child number, pare 


10.11 抓 出 走 了 TABLE ACCESS FULL 的 SQL 


12 from v$sql plan) 

i3 where rn - 2) b, 

14 v$sql c, . 

15 (select owner, segment_name, sum(bytes / 1024 / 1024) mb 

16 from dba segments 

17 group by owner, segment name) d 

18 where р.591 id = c.sqgl id 

19 and b.child number = c.child number 

20 and b.object owner - 'SCOTT' 

21 апа a.sql id = b.sql id 

22 and a.child number - b.child number 

23 and a.operation like '$NESTED LOOPS$' 

24 and a.id = b.parent id 

25 and b.operation - 'TABLE ACCESS' 

26 and b.options - 'FULL' 

27 and b.object owner = d.owner 

28 and b.object name = d.segment name 

29 order by 4 desc; 
SQL TEXT SOL ID OBJECT NAME MB 
select /*- use nl(a,b) full(a) full(b) */ * 6prgcr0qcj3ar B 9 


from a, b where a.object id - b.object id 


此 脚本 不 依赖 统计 信息 。 

如 果 一 个 大 表 走 了 全 表 扫 描 ， 会 严重 影响 SQL 性 能 。 这 时 我 们 可 以 查看 大 表 与 谁 进行 关 
联 。 如 果 大 表 与 小 表 《〈 小 结果 集 ) 关联 ， 我 们 可 以 考虑 让 大 表 作 为 嵌 套 循环 被 驱动 表 ， 大 表 走 
连接 列 索引 。 如 果 大 表 与 大 表 (大 结果 集 ) 关联 , 我 们 可 以 检查 大 表 过 滤 条 件 是 否 可 以 走 索 引 ， 
也 要 检查 大 表 被 访问 了 多 少 个 字段 。 假 设 大 表 有 50 个 字段 ， 但 是 只 访问 了 其 中 5 个 字段 ， 这 
时 我 们 可 以 建立 一 个 组 合 索引 ， 将 where 过 滤 字 段 、 表 连接 字段 以 及 select 访问 的 字段 组 合 在 
一 起 ， 这 样 就 可 以 直接 从 索引 中 获取 数据 ， 避 免 大 表 全 表 扫 描 ， 从 而 提升 性 能 。 下 面 脚本 抓 出 
走 了 全 表 扫 描 的 SQL， 同 时 显示 访问 了 表 多 少 个 字段 ， 表 一 共有 多 少 个 字段 以 及 表 段 大 小 。 


select a.sql_id, 
a.sql text, 
d.table name, 
REGEXP COUNT(b.projection, ']') |I'/'I|| d.column cnt column cnt, 
c.size mb, 
b.FILTER PREDICATES filter 
from v$sql а, 
v$sql plan b, 
(select owner, segment name, sum(bytes / 1024 / 1024) size mb 
from dba segments 
group by owner, segment name) c, 
(select owner, table name, count(*) column cnt 
from dba tab cols 
group by owner, table name) d 
a.sgl id = b.sql id 
and a.child number - b.child number 
and b.object owner - c.owner 
and b.object name = c.segment name 
b 
b 






pet, [ " 


where 


1 


апа b.object_owner = d.owner 
and b.object_name = d.table_name 
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and c.owner = 'SCOTT' 
and b.operation = 'TABLE ACCESS' 
and b.options = 'FULL' 


order by 5 desc; 


在 Scott 账户 中 运行 如 下 SQL. 


і select owner,object name from t where object 14>100; 


使 用 脚本 将 其 抓 出 。 


SQL» select a.sql id, 


2 a.sql text, 
3 d.table name, 
4 REGEXP COUNT(b.projection, ']') || '/' || d.column cnt column cnt, 
5 c.size mb, 
6 b.FILTER PREDICATES filter 
d from v$sql a, 
8 v$sql plan b, 
9 (select owner, segment name, sum(bytes / 1024 / 1024) size mb 
10 from dba segments 
11 group by owner, segment name) c, 
12 (select owner, table name, count(*) column cnt 
¿3 from dba tab cols 
14 group by owner, table name) d 
15 where a.sql id = Ь.ѕ91 id 
16 and a.child number = b.child number 
17 and b.object owner = c.owner 
18 and b.object name - c.segment name 
19 and b.object owner - d.owner 
20 and b.object name = d.table name 
21 and c.owner = 'SCOTT' 
22 and b.operation = 'TABLE ACCESS' 
23 and b.options = 'FULL' 
24 order by 5 desc; 
SOL ID SQL TEXT TABLE NAME COLUMN CNT SIZE MB FILTER 
51mu5j3aydw94 select owner,object name from t T 2/15 9 


在 实际 工作 中 ， 我 们 可 以 对 脚本 适当 修改 ， 比 如 过 滤 出 大 于 1GB 的 表 、 过 滤 出 表 总 字段 
数 大 于 20 的 表 、 过 滤 出 访问 了 超过 10 个 字段 的 表 等 。 


此 脚本 不 依赖 统计 信息 。 

我 们 在 第 4 章 中 提 到 , INDEX FULL SCAN 会 扫描 索引 中 所 有 的 叶子 块 ， 单 块 读 。 如 果 索 
引 很 大 ， 执 行 计 划 中 出 现 了 INDEX FULL SCAN， 这 时 SQL 会 出 现 严重 的 性 能 问题 ， 因 此 我 
们 需要 抓 出 走 了 INDEX FULL SCAN 的 SQL. 以 下 脚本 抓 出 走 了 INDEX FULL SCAN 的 SQL 
并 且 根据 索引 段 大 小 降序 显示 。 


select c.sql_text, c.sql_id, b.object_name, d.mb 
from v$sql plan b, 
v$sql c, 
(select owner, segment name, sum(bytes / 1024 / 1024) mb 





10.13. 抓 出 走 了 INDEX SKIP SCAN 的 SQL 


from dba segments 
group by owner, segment name) d 


where b.sgl id = c.sgl id 

and b.child number = c.child number 

and b.object owner = 'SCOTT' 

and b.operation = 'INDEX' 

and b.options - 'FULL SCAN' 

and b.object owner = d.owner 

and b.object name = d.segment name 
order by 4 desc; 


我 们 在 Scott 账户 中 运行 如 下 SQL. 


і select * from t where object id is not null order by object id; 


在 object id 列 创建 索引 之 后 ， 执 行 上 面 SQL 会 自动 走 INDEX FULL SCAN， 使 用 脚本 将 
其 抓 出 。 


SOL» select c.sql_text, c.sql_id, b.object name, d.mb 
2 from v$sql plan b, 
3 v$sql c, 
4 (select owner, segment name, sum(bytes / 1024 / 1024) mb 
5 from dba segments 
6 group by owner, segment name) d 
7 
8 


where b.sgl id = c.sql_id 
and b.child number - c.child number 

9 and b.object owner - 'SCOTT' 

10 and b.operation - 'INDEX' 

11. апа b.options = 'FULL SCAN' 

12 апа b.object_owner = d.owner 

13 and b.object name = d.segment name 

14 order by 4 desc; 
SOL TEXT SOL ID OBJECT NAME MB 
select * from t where object id  fkan9h6frsn90 IDX ID 2 


is not null order by object id 


在 实际 工作 中 ， 我 们 可 以 对 脚本 作 适 当 修 改 ， 例 如 过 滤 出 大 于 10GB 的 索引 。 





此 脚本 不 依赖 统计 信息 。 
当 执 行 计 划 中 出 现 了 INDEX SKIP SCAN, 通常 说 明 需 要 额外 添加 一 个 索引 。 以 下 脚本 抓 
出 走 了 INDEX SKIP SCAN 的 SQL。 


select c.sql text, c.sql id, b.object name, d.mb 
from v$sql plan b, 
v$sql c, 
(select owner, segment name, sum(bytes / 1024 / 1024) mb 
from dba segments 
group by owner, segment name) d 
where b.sqgl id = c.sql id 
and b.child number - c.child number 
and b.object owner = 'SCOTT' 
and b.operation - 'INDEX' 
and b.options - 'SKIP SCAN' 
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and b.object_name = d.segment name 


and b.object owner - d.owner 
order by 4 desc; 


在 Scott 账户 中 创建 如 下 测试 表 。 
| SOL» create table t skip as select * from dba objects; 


Table created. 


在 owner 字段 上 创建 一 个 索引 。 
| SQL» create index idx owner id on t skip(owner,object id); 


Index created. 


对 表 收 集 统计 信息 。 


SQL» BEGIN 
DBMS STATS.GATHER TABLE STATS (ownname => "SCOTI, 
tabname => UD SKIB', 
estimate percent => 100, 
method opt -» 'for all columns size skewonly', 

no invalidate -» FALSE, 
degree => 1, 
cascade => TRUE); 

END; 

/ 


O хо 0 -J 9 Qn > ом 


H 


PL/SQL procedure successfully completed. 


执行 如 下 SQL 并 且 查 看 执行 计划 。 
SQL> select * from t skip where object id < 100; 


98 rows selected. 


Execution Plan 


Plan hash value: 979686564 


| Id |Operation | Name |Rows| Bytes | Cost ($CPU)| Time 


| 0 |SELECT STATEMENT | |7791) 8827 «| 95 (0)1 00:00:02 | 
| 1 | TABLE ACCESS BY INDEX ROWID|T SKIP |” 91| 58827 | 95 (0) | 00:00:02 | 
|% 2 | INDEX SKIP SCAN |IDX OWNER ID| 91| | 92 (0) | 00:00:02 | 


2 - access("OBJECT ID"«100) 
filter("OBJECT ID"«100) 


通过 脚本 抓 出 走 了 INDEX SKIP SCAN 的 SQL. 


SQL> select c.sql text, c.sql id, b.object_name, d.mb 
2 from v$sql_plan b, š 
3 у$за1 с, 
4 (select owner, segment_name, sum(bytes / 1024 / 1024) mb 
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1014 . 抓 出 索引 被 哪些 SQL 引用 


5 from dba segments 

6 group by owner, segment name) d 
7 

8 






where b.sql_id = c.sql id 
and b.child number = c.child number 

9 and b.object owner = 'SCOTT' 

10 and b.operation = 'INDEX' 

11 and b.options - 'SKIP SCAN' 

12 and b.object owner - d.owner 

13 and b.object name - d.segment name 

14 order by 4 desc; 
SQL TEXT SQL ID OBJECT NAME MB 
select * from t skip where object id < 100 0837hu8zxha2y IDX OWNER ID 2 


此 脚本 不 依赖 统计 信息 。 

有 时 开发 人 员 可 能 会 胡乱 建立 一 些 索 引 , 但 是 这 些 索引 在 数据 库 中 可 能 并 不 会 被 任何 一 
个 SQL 使 用 。 这 样 的 索引 会 增加 维护 成 本 ， 我 们 可 以 将 其 删 掉 。 下 面 脚本 查询 SQL 使 用 哪 
些 索引 。 


select a.sql_text, a.sql_id, b.object owner, b.object name, b.object type 
from v$sgl a, v$sql plan b 
where a.sgl id = b.sqgl id 
and a.child number - b.child number 
and object owner - 'SCOTT' 
and object type like '$INDEX$' 
order by 3,4,5; 


我 们 在 Scott 账户 中 运行 下 面 SQL 并 且 查 看 执行 计划 。 
SQL> select * from t where object_id<100; 
98 rows selected. 


Execution Plan 


Plan hash value: 827754323 


| Id | Operation | Name | Rows | Bytes | Cost (%СРО)| Time | 
| 0] SELECT STATEMENT | | 91 (|- 88273] 4 (0)| 00:00:01 | 
| 1 | TABLE ACCESS BY INDEX ROWID| T | gi | 8827 | 4 (0)] 00:00:01 | 
I* 211 INDEX RANGE SCAN | IDX_ID | 9171 | 2 (0)| 00:00:01 | 


2 - access("OBJECT ID"«100) 


我 们 通过 脚本 将 它 抓 出 。 


| SQL> select a.sql text, a.sql ій, b.object owner, b.object name, b.object type 
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2 from v$sql a, v$sql_plan b 

3 where a.sgl id = b.sql id 

4 and a.child number - b.child number 
5 and object owner - 'SCOTT' 

6 and object type like '$INDEXS$' 

7 order by 3,4,5; 






SQL TEXT SQL ID OBJECT OWNER OBJECT NAME OBJECT TYPE 
select * from t where object id«100 Опур2р03р06к4 SCOTT IDX ID INDEX 


此 脚本 不 依赖 统计 信息 。 
我 们 在 第 5 章 中 提 到 过 笛 卡 儿 积 连 接 。 当 两 表 没 有 关联 条 件 的 时 候 就 会 走 笛 卡 儿 积 ， 当 
Rows 被 估算 为 1 的 时 候 ， 也 可 能 走 笛 卡 儿 积 连接 。 下 面 脚本 抓 出 走 了 笛 卡 儿 积 的 SQL. 


select c.sql text, 

‘Sql id, 

.object name, 

.filter predicates filter, 

-ассевв predicates predicate, 

.mb 

from v$sql plan a, 

(select * 
from (select sql id, 

child number, 
object owner, 
object name, 
parent id, 
operation, 
options, 
row number() over(partition by sql id, child number, parent id 


O. p p D p 


order by id) rn 
from v$sql plan) 
where rn - 1) b, 
v$sql c, 
(select owner, segment name, sum(bytes / 1024 / 1024) mb 
from dba segments 
group by owner, segment name) d 
where b.sgl id = c.sgl id 
and b.child number - c.child number 
and b.object owner - 'SCOTT' 
and a.sql id = b.sqgl id 
and a.child number - b.child number 
and a.operation = 'MERGE JOIN' 
and a.id - b.parent id 
and a.options = 'CARTESIAN' 
and b.object owner - d.owner 
and b.object name - d.segment name 
order by 4 desc; 


在 Scott 账户 中 运行 如 下 SQL. 


[ select * from a,b; 


利用 脚本 将 其 抓 出 。 


1046 ” 抓 出 走 了 错误 的 排序 合并 连接 的 SAL 


SOL» select c.sgl text, 


2 a.sgl id, 
3 b.object name, 
4 a.filter predicates filter, 
5 a.access predicates predicate, 
6 d.mb 
7 from v$sql plan a, 
8 (select * 
9 from (select 591 id, 
10 child number, 
31, object_owner, 
kg object name, 
13 parent id, 
14 operation, 
15 options, 
16 row number() over(partition by sql id, child number, parent id order 
by id) rn 
Ш. from у$591 plan) 
18 where гп = 1) b, 
19 Y$Sql с, 
20 (select owner, segment_name, sum(bytes / 1024 / 1024) mb 
21 from dba segments 
22 group by owner, segment name) d 
23 where b.sql id = c.sql id 
24 and b.child number = c.child number 
25 and b.object owner = 'SCOTT' 
26 and a.sgl id = b.sql іа 
27 and a.child number - b.child number 
28 and a.operation - 'MERGE JOIN' 
29 and a.id = b.parent id 
30 and a.options = 'CARTESIAN' 
31 and b.object owner - d.owner 
32 and b.object name - d.segment name 
33 order by 4 desc; 
SOL TEXT SQL ID OBJECT NAME FILTER PREDICATE MB 
select * from a,b 9kwdjbbs50kcu A 9 





此 脚本 不 依赖 统计 信息 。 

排序 合并 连接 一 般 用 于 非 等 值 关 联 ， 如 果 两 表 是 等 值 关联 ， 我 们 建议 使 用 HASH 连接 代 
奉 排序 合并 连接 ， 因 为 HASH 连接 只 需要 将 驱动 表 放 入 РСА 中 ， 而 排序 合并 连接 要 么 是 将 两 
个 表 放 入 РСА |, 要么 是 将 一 个 表 放 入 РСА 中 、 另 外 一 个 表 走 INDEX FULL SCAN， 然 后 回 
表 。 如 果 两 表 是 等 值 关 联 并 且 两 表 比 较 大 ， 这 时 应 该 走 HASH 连接 而 不 是 排序 合并 连接 。 下 
面 脚本 抓 出 两 表 等 值 关联 但 是 走 了 排序 合并 连接 的 SQL， 同 时 显示 离 MERGE JOIN 关键 字 较 
远 的 表 的 段 大 小 ( 太 大 PGA 放 不 下 )。 


select c.sql_id, c.sql text, d.owner, d.segment name, d.mb 
from v$sql plan a, 
v$sqgl plan b, 
v$sql c, 
(select owner, segment name, sum(bytes / 1024 / 1024) mb 
from dba segments 
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П 10x 全 自动 SQL 审核 
group by owner, segment name) d 
where a.sql id = b.sql id 
and a.child number - b.child number 
and b.operation = 'SORT' 
and b.options = 'JOIN' 
and b.access predicates like '$"-"$' 
and a.parent id - b.id 
and a.object owner = 'SCOTT' 
and b.sql id = c.sgl id 
and b.child number = c.child number 
and a.object owner - d.owner 


and a.object name = d.segment name 
order by 4 desc; 


我 们 在 Scott 账户 中 运行 下 面 SQL 并 且 查 看 执行 计划 。 


SQL» select /*+ use merge(e,d) */ * 
2 from emp e, dept d 
3 where e.deptno - d.deptno; 

14 rows selected. 


Execution Plan 


| Id | Operation | Name | Rows | Bytes | Cost ($CPU)|Time 

| 0 | SELECT STATEMENT | | 14 | 812 | 6 (17)100:00:01| 
| 1 | MERGE JOIN | | 14 | 812 | 6 (17) 100:00:01]1 
| 27? TABLE ACCESS BY INDEX ROWID| DEPT | 4 | 80 | 2 (0) 100:00:01| 
| >] INDEX FULL SCAN | PK DEPT | 4 | | 1 (0) 100:00:01| 
|* 4 | SORT JOIN | | 14 | 532" | 4 (25) 100:00:01| 
TE TABLE ACCESS FULL | EMP | 14 | 532 | 3 (0)100:00:01| 


Predicate Information (identified by operation id): 


4 – access("E"."DEPTNO"-"D". "DEPTNO") 
filter("E"."DEPTNO"-"D"."DEPTNO") 


我 们 使 用 脚本 将 走 了 排序 合并 连接 的 SQL 抓 出 , 同时 显示 离 MERGE JOIN 关键 字 较 远 的 
表 的 段 大 小 。 


SQL> select c.sql_id, c.sql_text, d.owner, d.segment_name, d.mb 

2 from v$sql_plan a, 

3 v$sqgl plan b, 

4 v$sql c, 

5 (select owner, segment name, sum(bytes / 1024 / 1024) mb 
6 from dba segments 

7 group by owner, segment name) d 

8 where а.в41 id = b.sql id 

9 and a.child number = b.child number 
10 and b.operation = 'SORT' 

11 and b.options -''JOIN' 
12. and b.access predicates like '%"="%' 
13 and a.parent id - b.id 
14 and a 
15 and b. 


“Object owner = "SCOTT! 
sql id = c.sql id 
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10.17 抓 出 LOOP € LOOP 的 PSQL 


16 and b.child number = c.child number 

17 and a.object owner = d.owner 

18 and a.object name - d.segment name 

19 order by 4 desc; 
SQL ID SQL TEXT OWNER SEGMENT NAME MB 
c7gd7wnO0gx4vq select /%% use merge(e,d) */ * from emp e, SCOTT EMP .0625 


dept d where e.deptno - d.deptno 


此 脚本 不 依赖 统计 信息 。 

在 编写 PLSQL 的 时 候 ， 我 们 应 该 尽量 避免 LOOP 套 LOOP， 因 为 双 层 循环 ， 最 内 层 循 环 
类 似 笛 卡 儿 积 。 假 设 外 层 循环 返回 1 000 行 数据 ， 内 层 循环 返回 1000 行 数 据 ， 那 么 内 层 循环 
里 面 的 代码 就 会 执行 1000*1000 次 。 以 下 脚本 可 以 抓 出 LOOP € LOOP 的 PLSQL. 


with x as 

(select /*+ materialize */ owner,name,type,line,text,rownum rn from dba source where 
(upper (text) like '%END%LOOP%' or upper (text) like '$FOR£LOOP£')) 
select a.owner,a.name,a.type from x a,x b 

where ((upper(a.text) like '$END$LOOP$' 

and upper(b.text) like '%END%LOOP$%' 

and a.rn*1-b.rn) 

or (upper(a.text) like '$FORS$SLOOPS' 

and upper(b.text) like '$FORSLOOP$' 

and а.гп+1=р.гп)) 

and a.owner-b.owner 

and a.name-b.name 

and a.type-b.type 

and a.owner-'SCOTT'; 


我 们 在 Scott 账户 中 创建 LOOP Ж LOOP 的 存储 过 程 。 


create or replace procedure p_99 is 
begin 
for i in 1 .. 9 loop 
dbms output.put line(''); 
for x in 1 .. 9 loop 
if (i >= x) then 
dbms output.put("* 7 |] à (| "ox ' IE x IL t m" Ip à * x) 
end if; 
end loop; 
dbms output.put line(''); 
end loop; 
end; 


我 们 通过 脚本 将 以 上 的 存储 过 程 抓 出 。 


SQL> with x as 

(select /*+ materialize */ owner,name,type,line,text,rownum rn from dba_source 
where (upper(text) like '%END%LOOP%' or upper (text) like '$£FOR$LOOP$')) 

select distinct a.owner,a.name,a.type from x a,x b 

where ((upper(a.text) like 'S$ENDSLOOP$' 

and upper(b.text) like '$SENDSLOOPZS' 

апа a.rn*l-b.rn) 

or (upper(a.text) like '$FORSLOOP$' 


со 14 OY Cn i CJ Мо 
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as 





9 and upper(b.text) like '%ЕОВ%ГООР$%' 
10 and a.rn*l-b.rn)) 


11 and a.owner-b.owner 

12 and a.name-b.name 

13 and a.type-b.type 

14 апа a.owner-'SCOTT'; 
OWNER NAME TYPE 
SCOTT E: 99 PROCEDURE 





此 脚本 依赖 统计 信息 。 





如 果 一 个 索引 选择 性 很 低 ， 说 明 列 数据 分 布 不 均衡 。 当 SQL 走 了 数据 分 布 不 均衡 列 的 索 
引 ， 很 容易 走 错 执行 计划 ， 此 时 我 们 应 该 检查 SQL 语句 中 是 否 有 其 他 过 滤 条 件 ， 如 果 有 其 他 
过 滤 条 件 ， 可 以 考虑 建立 组 合 索引 ， 将 选择 性 高 的 列 作为 引导 列 ; 如 果 没 有 其 他 过 滤 条 件 ， 应 
该 检查 列 是 否 有 收集 直方 图 。 以 下 脚本 抓 出 走 了 低 选 择 性 索引 的 SQL. 


select c.sqil. id, 
c.sql text, 
b.index name, 
e.table name, 
trunc(d.num distinct / e.num rows * 100, 2) selectivity, 
d.num distinct, 
e.num rows 
from v$sqgl plan a, 
(select * 
from (select index owner, 
index name, 
table owner, 
table name, 
column name, 
count(*) over(partition by index owner, index name, table owne 
r, table name) cnt 
from dba ind columns) 
where cnt = 1) b, 
мевае, 
dba tab col statistics d, 
dba tables e 
where a.object owner = b.index owner 


and a.object name - b.index name 
and b.index owner = 'SCOTT' 

and a.access predicates is not null 
and а.вді id = c.sql id 

and à.child number - c.child number 
and d.owner = e.owner 

and d.table name = e.table name 

and b.table owner = e.owner 

and b.table name = e.table name 

and d.column name = b.column name 
and d.table name = b.table name 

and d.num distinct / e.num rows « 0.1; 


我 们 在 Scott 账户 中 执行 如 下 SQL 并 且 查 看 执行 计划 。 
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1048 ” 抓 出 走 了 低 选择 性 索引 的 SQL 


SQL> select * from t where owner='SYS'; 
23654 rows selected. 
Execution Plan 


Plan hash value: 2480948561 


| Id | Operation | Name | Rows | Bytes | Соз%(%СРО) |Тіпе 

| 0 | SELECT STATEMENT | | 2346 | 222K| 68 (0) 100:00:01| 
| 1 | TABLE ACCESS BY INDEX ROWIDI T | 2346 | 222K| 68 (0) |00:00:01| 
(% 2-4 INDEX RANGE 5САМ | IDX_OWNER | 2346 | | 6 (0) 100:00:01| 


2 - access (YOWNER"='SYS') 


Statistics 
1 recursive calls 
0 db block gets 
3819 consistent gets 
0 physical reads 
0 redo size 
2680901 bytes sent via SQL*Net to client 
17756 bytes received via SQL*Net from client 
1578  SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
23654 rows processed 


我 们 使 用 脚本 将 以 上 SQL 抓 出 。 


SQL» select с.з] id, 


2 c.sql text, 
3 b.index name, 
4 e.table name, 
5 trunc(d.num distinct / e.num rows * 100, 2) selectivity, 
6 d.num distinct, 
7 e.num rows 
8 from v$sql plan а, 
9 (select * 
10 from (select index owner, 
11 index name, 
12 table owner, 
13 table name, 
14 column name, 
15 count(*) over(partition by index owner, index name, table 
owner, table name) cnt 
16 from dba ind columns) 
17 where cnt = 1) b, 
18 v$sql c, 
19 dba tab col statistics а, 
20 dba tables e 
21 where a.object_owner = b.index owner 
22 and a.object name - b.index name 
23 and b.index owner - 'SCOTT' 
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24 and a.access_predicates is not null 

25 and a.sgl id = c.sql_id 

26 and a.child number - c.child number 

27 and d.owner = e.owner 

28 and d.table name = e.table name 

29 and b.table owner - e.owner 

30 and b.table name = e.table name 

31 and d.column name - b.column name 

32 and d.table name - b.table name 

33 and d.num distinct / e.num rows < 0.1; 
SQL ID SQL TEXT INDEX NAME TABLE NAME SELECTIVITY NUM DISTINCT МОМ ROWS 
6gzd8z5vm5k0t select * from t where owner-'SYS' IDX OWNER T -04 3 72734 









此 脚本 依赖 统计 信息 。 

我 们 在 第 1 章 中 讲 到 ， 回 表 次 数 太 多 会 严重 影响 SQL 性 能 。 当 执行 计划 中 发 生 了 回 表 再 
过 滤 并 且 过 渡 字 段 的 选择 性 比较 高 , 我 们 可 以 将 过 滤 字 段 包含 在 索引 中 避免 回 表 再 过 滤 ， 从 而 
减少 回 表 次 数 ， 提 升 查询 性 能 。 以 下 脚本 抓 出 回 表 再 过 滤 选 择 性 较 高 的 列 。 


select a.sql id, 
a.sql text, 
f.table name, 
c.size mb, 
e.column name, 
round(e.num distinct / f.num rows * 100, 2) selectivity 
from v$sql а, 
v$sql plan b, 
(select owner, segment name, sum(bytes / 1024 / 1024) size mb 
from dba segments 
group by owner, segment name) c, 
dba tab col statistics e, 
dba tables f 
where а.591 id = b.sqgl id 


and a.child number - b.child number 
and b.object owner = c.owner 

and b.object name - c.segment name 
and e.owner - f.owner 

and e.table name - f.table name 

and b.object owner = f.owner 

and b.object name - f.table name 


and instr(b.filter predicates, e.column name) » 0 
and (e.num distinct / f.num rows) > 0.1 
and c.owner - 'SCOTT' 
and b.operation = 'TABLE ACCESS' 
and b.options = 'BY INDEX ROWID' 
and e.owner - 'SCOTT' 
order by 4 desc; 


我 们 在 Scott 账户 中 运行 如 下 SQL. 
SQL» select * from t2 where object id«1000 and object name like 'T%'; 


26 rows selected. 


10.19 ， 抓 出 可 以 创建 组 合 索引 的 SQL ( 回 表 再 过 滤 选 择 性 高 的 列 ) 


Execution Plan 


Plan hash value: 921640168 


| 1164 | 19 (0) 100:00:01| 
| 1164 | 19 (0) 100:00:01| 
| | 4 (0)|00:00:01| 








一 





2 access ("OBJECT ID"«1000) 


Statistics 
1 recursive calls 
0 db block gets 
19 consistent gets 
0 physical reads 
0 redo size 
2479 bytes sent via SQL*Net to client 
430 bytes received via SQL*Net from client 
3 SQL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 
26 rows processed 


执行 计划 中 发 生 了 回 表 再 过 滤 ， 过 滤 字 段 的 选择 性 较 高 ,我 们 利用 脚本 将 以 上 SQL 抓 出 。 


SQL> select a.sql_id, 
a.sql text, 
f.table name, 
c.size mb, 
e.column name, 
round(e.num distinct / f.num rows * 100, 2) selectivity 
from v$sql а, 
v$sql plan b, 
(select owner, segment name, sum(bytes / 1024 / 1024) size mb 
from dba segments 
group by owner, segment name) c, 
dba tab col statistics e, 
dba tables f 
where a.sql id = b.sql id 
and a.child number - b.child number 
and b.object owner = c.owner 
and b.object name = c.segment name 


pa» p HHpPiIHB 
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18 and e.owner = f.owner 

19 and e.table name = f.table name 

20 and b.object owner = f.owner 

21 and b.object name = f.table name 

22 and instr(b.filter predicates, e.column name) > 0 
23 and (e.num distinct / f.num rows) » 0.1 

24 and c.owner = 'SCOTT' 

25 and b.operation - 'TABLE ACCESS' 
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26 and b.options = 'BY INDEX ROWID' 
27 and e.owner = 'SCOTT' 
28 order by 4 desc; 


SQL_ID SQL TEXT TABLE NAME SIZE MB COLUMN NAME SELECTIVITY 


fagathsuy5w3d select * from t2 where object id Т2 9 OBJECT NAME 0.94 


«1000 and object name like 'T$' 


此 脚本 不 依赖 统计 信息 。 

我 们 在 第 1 章 中 讲 到 ， 回 表 次 数 太 多 会 严重 影响 SQL 性 能 。 当 SQL 走 索引 回 表 只 访问 表 
中 少 部 分 字段 , 我 们 可 以 将 这 些 字段 与 过 滤 条 件 组 合 起 来 建立 为 一 个 组 合 索引 , 这 样 就 能 避免 
回 表 ， 从 而 提升 查询 性 能 。 下 面 脚本 抓 出 回 表 只 访问 少数 字段 的 SQL。 


select a.sql_id, 
a.sql text, 
d.table name, 
REGEXP. COUNT(b.projection, ']') |1'/'11 d.column cnt column cnt, 
c.size mb, 
b.FILTER PREDICATES filter 
from у$591 а, 
v$sql plan b, 
(select owner, segment name, sum(bytes / 1024 / 1024) size mb 
from dba segments 
group by owner, segment name) c, 
(select owner, table name, count(*) column cnt 
from dba tab cols 
group by owner, table name) d 
where a.sql id = b.sgl id 
and a.child number = b.child number 
and b.object owner = c.owner 
and b.object name - c.segment name 
and b.object owner - d.owner 
and b.object name - d.table name 
and c.owner - 'SCOTT' 
and b.operation - 'TABLE ACCESS' 
and b.options = 'BY INDEX ROWID' 
and  REGEXP COUNT(b.projection, ']')/d.column cnt«0.25 
order by 5 desc; 


我 们 在 Scott 账户 中 运行 如 下 SQL. 


SQL» select object name from t2 where object id«1000; 





Db 
3 





942 rows selected., 


Execution Plan 


Plan hash value: 921640168 


| Id | Operation | Name | Rows | Bytes | Cost($CPU)|Time 


| 0 | SELECT STATEMENT | | 917 | 27510 | 19 (0) 100:00:01| 


10.00 ” 抓 出 可 以 创建 组 合 索 引 的 SQL ( 回 表 只 访问 少数 字段 ) 


1 | TABLE ACCESS BY INDEX ROWID| T2 | 917 | 27510 | 19 (0)|00:00:01| 
s 21 INDEX RANGE SCAN | TOX T2 ID | 917 | | 4 (0)|00:00:01| 


一 一 一 一 二 一 一 一 一 二 一 一 一 一 一 一 一 一 二 二 二 二 二 一 一 二 二 一 一 二 一 一 二 二 二 二 一 二 一 一 二 一 一 一 一 一 二 一 一 一 一 一 一 一 一 一 一 一 一 一 中 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 一 


Predicate Information (identified by operation id): 


2 - access("OBJECT ID"«1000) 


Statistics 

0 recursive calls 
0 db block gets 

141 consistent gets 
0 physical reads 
0 redo size 

24334 bytes sent via SQL*Net to client 

1102 bytes received via SQL*Net from client 
64 SOL*Net roundtrips to/from client 
0 sorts (memory) 
0 sorts (disk) 

942 rows processed 


因为 上 面 SQL 回 表 只 访问 了 1 个 字段 ， 我 们 可 以 利用 脚本 将 上 面 SQL 抓 出 。 


SQL» select a.sql_id, 
a.sql text, 
d.table name, 
REGEXP COUNT(b.projection, ']') ||'/'|| d.column cnt column cnt, 
c.size mb, 
b.FILTER PREDICATES filter 
from v$sql a, 
v$sql plan b, 
(select owner, segment name, sum(bytes / 1024 / 1024) size mb 
from dba segments 
group by owner, segment name) c, 
(select owner, table name, count(*) column cnt 
from dba tab cols 
group by owner, table name) d 
where a.sgl id = b.sql id 
and a.child number - b.child number 
and b.object owner = c.owner 
and b.object name = c.segment name 
and b.object owner - d.owner 
and b.object name - d.table name 


мые p ы ы нуны 
Q (o 0 -1 OY (ла ш № = ооо м2 O0 O1 > ою) № 


21 and c.owner = 'SCOTT' 

22 and b.operation - 'TABLE ACCESS' 

23 and b.options = 'BY INDEX ROWID' 

24 and REGEXP COUNT(b.projection, ']')/d.column спЕ<0.25 

25 order by 5 desc; 

SOL ID SOL TEXT TABLE NAME COLUMN CNT SIZE MB FILTER 
bzyprvnc4lak8 select object name from t2 T2 1/15 9 


where object id«1000 
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随 着 数据 量 逐 年 增加 , 并 发 量 也 成 倍增 长 , SQL 性 能 逐渐 成 为 |T 
系统 设计 和 开发 时 重点 考虑 的 问题 之 一 。SQL 优 化 就 像 做 数学 
题 一 样 , 如 果 没 有 思路 , 那 你 将 无 从 下 手 。 本 书 旨 在 帮助 读者 建立 
SQL 优 化 理念 , 并 在 其 指导 下 快速 掌握 SQL 优 化 的 方法 和 技巧 。 


本 书 基于 Oracle 进 行 讲解 , 适合 数据 库 开 发 人 员 、 数据 库 运 维 及 
管理 人 员 、 数据 仓库 ETL、BI 报 表 开 发 人 员 以 及 数据 库 相 关 的 各 
类 技术 人 员 阅 读 。 鉴 于 SQL 优化 思想 在 任何 数据 库 中 都 殊 途 同 
归 , 因此 无 论 是 基于 MySQL、SQL Server, 还 是 基于 DB2 的 
技术 人 员 , 都 能 从 本 书 中 有 所 受益 。 


本 书 特色 


° 大 量 经 典 的 案例 ， 教 你 快速 构建 SQL 优 化 解决 方案 。 

。 教 你 编写 SQL 优化 全 自动 脚本 ， 快 速 提升 工作 效率 。 

° 每 个 知识 点 都 提供 了 相应 的 案例 及 源 代码 ， 方 便 读者 动手 实验 。 
° 叹为观止 的 优化 技巧 ， 菲 夷 所 思 的 优化 案例 。 
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